Skip site navigation (1)Skip section navigation (2)
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>