Device Drivers Which Include mkdir("/dev")

[Daniel Hellstrom]

Hi,

I think the main reason why the mkdir() is called in the first place, 
from for example rasta-io driver, is that once other drivers register 
their device pciN.devM into the /dev/pciboardN/devM it would fail if the 
the directory /dev/pciboardN has not been created. So it is an attempt 
to avoid mkdir() in all IO drivers and move themkdir() dependency up to 
the pciboardN driver instead. An alternative approach could be that 
rtems_io_register_name("/dev/pciboardN/devM") would actually make sure 
that /dev/pciboardN directory is created if does not exist? or by 
introducing a new supporting function rtems_io_register_name_dircreat()? 
However, I suppose that would mean we would drag in mkdir() routines in 
all cases even when the IO drivers are only registering devices directly 
under /dev/ which is the most common case.

Daniel

       

On 2021-02-20 20:31, Chris Johns wrote:
> On 21/2/21 5:29 am, Gedare Bloom wrote:
>> On Fri, Feb 19, 2021 at 5:26 PM Joel Sherrill <joel at rtems.org> wrote:
>>> On Fri, Feb 19, 2021, 5:32 PM Chris Johns <chrisj at rtems.org> wrote:
>>>> On 20/2/21 7:56 am, Joel Sherrill wrote:
>>>>> On Fri, Feb 19, 2021 at 2:51 PM Gedare Bloom <gedare at rtems.org
>>>>> <mailto:gedare at rtems.org>> wrote:
>>>>>
>>>>>      I think the suggestion is to provide a catch-all rather than try to add new
>>>>>      faults for every possible condition. This mkdir is a pretty esoteric fault
>>>>>      that is unlikely to happen in properly developed code.
>>>>>
>>>>> Then why shouldn't this just be a debug _Assert and value not check deliberately?
>>>> Will the call ever fail in production? Could a user configure RTEMS in a manner
>>>> that generates the failure?
>>>>
>>>>> Isn't an assert something that should not happen in a properly designed BSP. In
>>>>> this case, it would be the sysinit magic that would be utterly broken.
>>>> I would not step out as far as utterly broken but yes I see your point. There
>>>> are other places where we have taken this approach.
>>>>
>>>> If the lack of making a directory in GRLIB is handled by errors in the other
>>>> dependent calls then why not add some documentation to the BSP.
>>> Confirmation appreciated but it is making the directory to out a device node. The device node create will fail if there isn't a directory so this will return an error.
>>>
>>> https://git.rtems.org/rtems/tree/bsps/shared/grlib/pci/gr_rasta_io.c#n577
>>>
>>> Which means an assert is ok
>>>
>> I think an assert that /dev exists is fine within device drivers that
>> want to create device nodes on /dev. It's not their responsibility to
>> create the /dev tree, right?
> I agree. It means there is a system level initialisation issue. Maybe a sysint
> call that is fatal is added before drivers are initialised?
>
> Chris
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210223/41144a87/attachment-0001.html>