Date: Tue, 19 Feb 2019 14:48:17 -0600 From: "Apollo D. Sharpe, Sr." <demetrioussharpe@netscape.net> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-drivers@freebsd.org Subject: Re: Subdirectories for devfs Message-ID: <3a05792c-0e40-b661-6362-fe6d0b7e4a03@netscape.net> In-Reply-To: <CANCZdfrtYyow6mahW-RwXjaim1FNaQ1KgW02eq9dpM7J5j4i7Q@mail.gmail.com> References: <6b0fda65-edca-c250-4bd4-8a5f56a2ddba@netscape.net> <CANCZdfrtYyow6mahW-RwXjaim1FNaQ1KgW02eq9dpM7J5j4i7Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/19/19 1:10 PM, Warner Losh wrote: > Would require changes to both driver sources as well as to the > programs that use the driver nodes for different things. The effect of > that will vary from "hack one place in the code" to "extensive changes > are needed in dozens or hundreds of locations, many out of the tree". > > What's the motivation? My personal motivation is that I believe that making /dev more organized, with a hierarchical standard, could help streamline the system a bit. I also believe that it could make the development of user-space systems a bit easier in the long run. For instance, I consider it the beginnings of a maintenance nightmare to have to look into multiple spots for input devices. I think that it would be much more simple to have the capability of iterating through a specific path that only contains input devices. I feel the same way about each category of device. Which brings the benefit of one less thing to worry about when building subsystems that specifically communicate with a specific set of devices. Also, I think a more hierarchical /dev makes it easier to tell exactly what kind of device you're looking at when you're using the terminal or the file browser. Now, I realize that this most likely doesn't matter one way or the other for server usage cases. I also understand that both ways may amount to a null sum. However, I do think that this could definitely go a long ways towards: a). Giving us a better foundation for creating our own solutions rather than being forced to accept the current trend of being cornered into implementing Linux interfaces. I believe that FreeBSD is often an afterthought simply because a lot of developers simply don't want to muck about with certain parts of the kernel's infrastructure. b). Slightly lowering the bar for the creation of new solutions for/using BSD technology. Personally, finding information required to do certain things seems to be hit or miss when it comes to internals of FreeBSD. It almost always ends in me asking for info in multiple places, because the info isn't really in the man pages & the documentation for the kernel's code leaves a lot to be desired. c). Bringing order to a part of the system that seems to be a free-for-all. As told to me on the FreeBSD USB mailing list: "From the kernel side, some subsystems do create a hierarchy (or at least a subdir for a set of related devices), and others don't. There is no system-wide policy about it either way." Yes, I realize that I may be the only one who feels this way. No, this isn't a push for the overall BSD community to throw caution to the wind & jump head-first into this idea. I'm really trying to understand the magnitude of what it would take to do this privately. This is an area of FreeBSD that I think could be improved on. Obviously, there's a lot more work required before FreeBSD really becomes an outstanding desktop system, but I do think that a lot of the foundational work would have to come from organizing /dev. -- Regards, Apollo D. Sharpe, Sr.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3a05792c-0e40-b661-6362-fe6d0b7e4a03>