On Thu, Feb 18, 2021 at 12:52 PM Joel Sherrill <j...@rtems.org> wrote: > > > > 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.
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@rtems.org >> >> > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel