Device Drivers Which Include mkdir("/dev")

[Gedare Bloom]

On Thu, Feb 18, 2021 at 12:52 PM Joel Sherrill <joel at rtems.org> wrote:
>
>
>
> On Thu, Feb 18, 2021 at 11:52 AM Gedare Bloom <gedare at rtems.org> wrote:
>>
>> On Thu, Feb 18, 2021 at 10:20 AM Joel Sherrill <joel at rtems.org> wrote:
>> >
>> >
>> >
>> > On Thu, Feb 18, 2021 at 11:06 AM Gedare Bloom <gedare at rtems.org> wrote:
>> >>
>> >> On Thu, Feb 18, 2021 at 8:56 AM Joel Sherrill <joel at rtems.org> wrote:
>> >> >
>> >> > Hi
>> >> >
>> >> > There are a lot of Coverity issues related to device drivers which call mkdir("/dev") and ignore the return value. My first thought was that they should have (void) added since /dev could have been created by an earlier driver.
>> >> >
>> >> > Then it occurred to me that libcsupport/src/base_fs.c includes mkdir("/dev") and a fatal error if it cannot create it.
>> >> >
>> >> > Doesn't this mean that every call to mkdir("/dev") in a BSP or device driver is redundant? They should be removed since the base FS contents are always in place before any device drivers are called.
>> >> >
>> >> > Thoughts?
>> >> >
>> >>
>> >> Seems reasonable. You could probably add an assert that /dev exists.
>> >
>> >
>> > The creation of the device node will fail if /dev does not exist so I think that
>> > is covered.
>> >
>> > I think the call is pointless and changing it to stat() to make sure it exists
>> > just adds bulk to the driver/BSP dependencies.
>> >
>> > I think just deleting it seems prudent. There is an error path if it doesn't
>> > exist.
>> >
>>
>> ok. I was just suggesting conversion to an assert since that is some
>> good practice when you have a belief/assumption but aren't totally
>> convinced. It's fine with me either way. assert(mkdir("/dev") == -1)
>> or just delete it.
>
>
> Grrr.. I've looked again at the code and it is all Gaisler code doing something
> like mkdir("/dev/leonXXX"). It really could fail. This should be a fatal error
> and would seem to indicate that we need a grlib category of fatal BSP/driver
> errors.

Given the complexity of grlib, that would make some sense. Although
maybe we can make it a little more generic... FATAL_THIRD_PARTY_DRIVER
errors might be nicer on them, and can be reused

>>
>>
>> > --joel
>> >>
>> >>
>> >> > --joel
>> >> > _______________________________________________
>> >> > devel mailing list
>> >> > devel at rtems.org
>> >> > http://lists.rtems.org/mailman/listinfo/devel