On Thu, Feb 18, 2021 at 11:52 AM Gedare Bloom <ged...@rtems.org> wrote:
> On Thu, Feb 18, 2021 at 10:20 AM Joel Sherrill <j...@rtems.org> wrote:
> >
> >
> >
> > On Thu, Feb 18, 2021 at 11:06 AM Gedare Bloom <ged...@rtems.org> wrote:
> >>
> >> On Thu, Feb 18, 2021 at 8:56 AM Joel Sherrill <j...@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.
>
> > --joel
> >>
> >>
> >> > --joel
> >> > _______________________________________________
> >> > devel mailing list
> >> > devel@rtems.org
> >> > http://lists.rtems.org/mailman/listinfo/devel
>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
