Hello Sebastian, From: Sebastian Huber [sebastian.hu...@embedded-brains.de] Sent: Wednesday, February 28, 2018 11:55
> ----- Am 27. Feb 2018 um 13:11 schrieb Jakob Viketoft > jakob.viket...@aacmicrotec.com: > >> From: Joel Sherrill [j...@rtems.org] >> Sent: Monday, February 26, 2018 14:36 >>>> On Feb 26, 2018 8:27 AM, "Jakob Viketoft" <jakob.viket...@aacmicrotec.com> >>>> wrote: >> >>>> Hello Joel, >> >>>> From: Joel Sherrill [j...@rtems.org] >>>> Sent: Monday, February 26, 2018 12:21 >> >>>>> On Feb 26, 2018 5:13 AM, "Jakob Viketoft" <jakob.viket...@aacmicrotec.com> >>>>> wrote: >>>>>> E.g. could it be possible for the translation mechanism to look if there >>>>>> is >>>>>> already an errno defined and then return this instead of doing the error >>>>>> code >>>>>> translation? >> >>>>>> It seems like the translation I'm talking about happens in the >>>>>> rtems_deviceio_write() function in >>>>>> cpukit/libcsupport/src/sup_fs_deviceio.c >> >>>>> Completely random thought as I sit on a plane without code. >> >>>>> Add a field to the arguments structure for errno. See it to zero before >>>>> the >>>>> call. If it is set to non-zero after the call, then the driver wanted to >>>>> return >>>>> errno directly. Otherwise translate. >> >>>> This was my thought as well, I just wanted to bounce it off the RTEMS list >>>> and >>>> also possibly get official support for a feature as this. >> >>> Now boarded on a different plane and have had another round of thinking. >> >>> What if an RTEMS status code were added like RTEMS_STATUS_IN_ERRNO and we >>> don't >>> modify the arguments structure. Then a driver could return that status to >>> trip >>> -1 and errno. >> >> Yes, that would work just as well for us and is even less work / impact. >> >>> Just a thought. I think it would make the code cleaner but another core >>> developer should pipe up. I was up at 3am to catch a flight and could be >>> loopy. >>> :) >> >> Anyone else? :) > > I think you try to improve the wrong driver framework. This classic device > support is a legacy API. It is inflexible > and has a considerable overhead due to an excessive layering and the use of > minor numbers. A driver registered > via IMFS_make_generic_node() already provides the functionality you are > asking. I agree with the excessive layering, but it's not straightforward how IMFS_make_generic_node() works. Looking at e.g. https://git.rtems.org/rtems/tree/testsuites/libtests/newlib01/init.c, it seems like driver *user* is calling IMFS_make_generic_node() which seems a bit absurd (correct me if I'm wrong). You also noted that the API isn't stable yet which make me hesitate about switching over to this. Practically speaking, I think need we have to have an immediate interim solution, along the lines Joel suggested, and then long term we could switch over to the IMFS_make_generic_node() way of doing things. However, I would need some more documentation on IMFS_make_generic_node() besides looking at examples in testsuites code. The current POSIX API is what's exposed to our users and changing that in any way is not done at the flip of a coin. We don't have any other filesystems in RTEMS (apart from /dev/*) if that has any impact either way. /Jakob _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
