Discussion:
[USB] Device information from userspace
(too old to reply)
Brennan Ashton bashton@brennanashton.com [nuttx]
2015-12-01 17:27:26 UTC
Permalink
Right now there is no way from userspace to get information on USB devices
that are attached besides the device name. I have an application with
multiple devices that show up as USB serial devices and get enumerated as
/dev/ttyUSB0...3 Occasionally these device will enumerate in a different
order and then I do not know what is what. In Linux we have two things
that help with this problem udev and links like /dev/serial/by-id/.

I was thinking about creating a readonly interface under procfs that would
give some information about the attached usb devices.

An alternative would be to just use custom device names for each of the
devices, but I do not get super excited about this, as in some cases it is
the SN that differentiates them.

--Brennan
spudarnia@yahoo.com [nuttx]
2015-12-01 17:56:04 UTC
Permalink
The seems like an appropriate use for procfs. Make sure that a user can exclude the interface if it is not needed.
spudarnia@yahoo.com [nuttx]
2015-12-01 18:16:06 UTC
Permalink
No, the more I think about this concept the more opposed I get. I want to be fair and flexible, but this is just the wrong way to go in my way of thinking. It violates every concept of partitioning of functionality and layering of the architecture that I can imagine.


For example, how would a GPIO driver work? Would you specify the port number and pin number? Would you want to configure the GPIO for application space too? Only the board knows that kind of detail. A board-independent application should not have that knowledge.


Would the application expect to get GPIO interrupts? No, that is not going to happen.


Would the application have to know I2C device numbers? SPI chip select pins?


No, I definitely won't go this way.


There is really not difference between writing a driver the "correct" way (in C as part of the OS) or the ad hoc way by putting a bunch of garbage in your application and using wild, crap interfaces with OS. I see no advantage. The device/board knowledge has to exist somewhere and that somewhere is only the board-specific logic under configs/ that is build into the OS.


Greg
Michael Smith drziplok@gmail.com [nuttx]
2015-12-01 18:33:41 UTC
Permalink
Just to offer some counter-examples, based on having done this successfully many times.

Firstly - many if not most embedded applications are board-specific, because they’re part of a larger system that includes the board and the things connected to it.

There’s often a strong desire to avoid making modifications to the OS, particularly when the thing being interfaced to is weird or custom, or just not likely to be interesting to the OS community.

The GPIO driver is actually a great example of where you want the chip or board to be a replaceable / upgradeable component within the larger system; the *behaviour* associated with the GPIO is a system / application thing, but the banging of the bits to make the GPIO do what it does is chip-specific. So you want to expose the GPIO with a standard protocol, and a standard way of finding the right GPIO (by name, etc.) but you don’t want to put anything specific to the application into the OS side of things.

Applications can and do receive signals; I don’t think it’s unreasonable to bind signals to asynchronous hardware events (that’s what poll does at the end of the day, after all), so why should GPIO events be any different?

On the subject of I2C, if the application is bound to the system, why shouldn’t it know what I2C slave IDs are in use? Here there’s the whole chip / board / system question, but I2C is routinely used as an off-board interface (regardless of whether that’s a sensible idea or not). Why shouldn’t an application be capable of being the delivery mechanism for code to support such a device?

SPI is really the same thing once you substitute “named GPIO discovery” for “slave address”.


For single-image NuttX systems, it’s trivial to write what is effectively a TSR or loadable that implements a ‘device driver’ that uses the bus-level interfaces - if there was a comparable mechanism for kernel systems (i.e. loadable driver modules) that would address the issue of having to modify and maintain a modified version of the OS.

= Mike
Post by ***@yahoo.com [nuttx]
No, the more I think about this concept the more opposed I get. I want to be fair and flexible, but this is just the wrong way to go in my way of thinking. It violates every concept of partitioning of functionality and layering of the architecture that I can imagine.
For example, how would a GPIO driver work? Would you specify the port number and pin number? Would you want to configure the GPIO for application space too? Only the board knows that kind of detail. A board-independent application should not have that knowledge.
Would the application expect to get GPIO interrupts? No, that is not going to happen.
Would the application have to know I2C device numbers? SPI chip select pins?
No, I definitely won't go this way.
There is really not difference between writing a driver the "correct" way (in C as part of the OS) or the ad hoc way by putting a bunch of garbage in your application and using wild, crap interfaces with OS. I see no advantage. The device/board knowledge has to exist somewhere and that somewhere is only the board-specific logic under configs/ that is build into the OS.
Greg
spudarnia@yahoo.com [nuttx]
2015-12-01 18:42:47 UTC
Permalink
Hi, Mike,


I agree with everything that you are saying. If you have control over the whole system, then you can manage the platform-specific knowledge in any way that you want.


But NuttX is not the whole system. I am less concerned about the existence of such drivers in the repository then I an with any application in the repository that actually uses them.


My position is that if you are going to implement applications that implement platform-specific knowledge, then also free to implement your own drivers in any way that you would like. I just won't carry them in the repository because, from my point of view, they are just a ticking time bomb.


Greg
spudarnia@yahoo.com [nuttx]
2015-12-01 18:47:24 UTC
Permalink
In fact, I encourage people using a FLAT build to not even bother with drivers. Just access the low level, board code directly from your application. Why not?


Similarly, I could not incorporate such things into the repository because I have to enforce strict OS interfaces (just as I also have to enforce strict layering of knowledge and control). But people should feel free to do whatever they need/want to do in they implementations to make things work.


Greg
Brennan Ashton bashton@brennanashton.com [nuttx]
2015-12-01 18:55:53 UTC
Permalink
(I renamed the subject to actually be in the correct thread again)

Greg,
Would you be receptive if I created something under procfs (like the Linux
sysfs interfaces) that provided some minimal interfaces for these. It
would then be under the board specific logic. That means that I have a
Nuttx HW API in micropython that talks to these endpoints, and it is up to
you to write those interfaces for your board. This also means you can only
expose certain ports on your board and not have a user application
tampering with the power monitor device the OS is exposing.

I have to go ahead with something for my project, and I would prefer that I
take an approach that is best received by the community at large.

I am not trying to create a system that encourages people to break the
barrier between the hardware interfaces and the user application.

--Brennan
Post by ***@yahoo.com [nuttx]
Hi, Mike,
I agree with everything that you are saying. If you have control over the
whole system, then you can manage the platform-specific knowledge in any
way that you want.
But NuttX is not the whole system. I am less concerned about the
existence of such drivers in the repository then I an with any application
in the repository that actually uses them.
My position is that if you are going to implement applications that
implement platform-specific knowledge, then also free to implement your own
drivers in any way that you would like. I just won't carry them in the
repository because, from my point of view, they are just a ticking time
bomb.
Greg
spudarnia@yahoo.com [nuttx]
2015-12-01 19:27:36 UTC
Permalink
Would you be receptive if I created something under procfs (like the Linux sysfs interfaces) that provided some minimal interfaces for these. It would then be under the board specific logic. That means that I have a Nuttx HW API in micropython that talks to these endpoints, and it is up to you to write those interfaces for your board. This also means you can only expose certain ports on your board and not have a user application tampering with the power monitor device the OS is exposing.
The procfs is a great tool for dressing up a number of achitectural sins. And there is precedent for this (just as there is also precedent for bus character drivers). There is already MCU-specific procfs entries (STM32 CCM memory usage). So why not board, specific procfs entries?.


A nasty part of this would be that there is currently no dynamic registration of procfs entries so you would have to put board-specific conditional logic in fs/procfs. Yech -- that is another thing on my list of things to fix.


The nuttx procfs is also read-only. I am not sure if that is strictly enforced or if there just don't happen to be any writable procfs entries(?). I would have to check.


But, then, why not board specific character drivers. Nothing prevents you from putting any kind of driver that you want in your configs/<board>/src. I don't have very much concern for what you do in the configs/<board>/src directories.
I have to go ahead with something for my project, and I would prefer that I take an approach that is best received by the community at large.
Of course, you should do whatever you need to do to be successful on your project. My concerns are with the roadmap for the OS and user-space drivers is not on that road map. Don't base what you do on whether it can be accepted upstream or not.
I am not trying to create a system that encourages people to break the barrier between the hardware interfaces and the user application.
Board specific implementations do minimize my concerns. Something in drivers/ raises more issues.


But, having gotten all of this off of my chest, if there were a patch for a especially well implemented GPIO/SPI/I2C character driver, I would probably commit that too. "Especially clean" would mean conforming to the coding standard and a correct character driver (probably just implementing IOCTL calls?). Any such driver should also perform only complete, atomic transactions. For example, for SPI driver a complete transaction would be "transfer data". "Select device" would not be complete.


Eating a little crow now and then is good for the spirit.


But I think I would not commit any application that actually uses those drivers. I can't imagine any scenario where that would be a good thing.


Greg
spudarnia@yahoo.com [nuttx]
2015-12-01 21:13:27 UTC
Permalink
Post by ***@yahoo.com [nuttx]
A nasty part of this would be that there is currently no dynamic registration of procfs entries so you would have to put board-specific conditional logic in fs/procfs. Yech -- that is another thing on my list of things to fix.
Okay.. I plugged that one too. procfs now does support dynamic register of procfs entreis provided that CONFIG_FS_PROCFS_REGISTER=y is selected. You should now be able to call procfs_regsiter(entry) to add a new entry to the procfs file system.

This was pretty much a quick'n'dirty add-on. I would have preferred some cleaner link list solution. But the existing const table was pretty well entrenched and I just did a little sleight-of-hand realloc'ing to accomplish a dynamic extension of the table. Might want to revisit that in the future.

Greg

Loading...