In message <[EMAIL PROTECTED]>, Kris Kennaway writes:
>
>On Tue, Nov 19, 2002 at 12:16:49AM -0800, Kip Macy wrote:
>> This doesn't sound like an intrinsic limitation of
>> devfs, just an issue with how it is structured now.
s/structured/used by drivers/
>> There should just be a central file for all the=20
>> devices which devfs sucks in at build (or maybe boot)=20
>> time specifying the appropriate permissions and any
>> other configuration information.
>
>No, the default permissions are specified in the driver source code
>via make_dev().
I guess one cannot be trapped in an airport for more than 24 hours
before people start fighting over ones code :-)
A major design-goal of DEVFS is to avoid that or more central files
have to know about all device drivers. Adding a new such file
is not acceptable.
On the other hand, knowing special UID and GID values in the kernel
is quite a hack as well.
IMO, the current situation is a fair compromise:
1. (+) We do not need MAKEDEV anymore.
2. (-) For some time yet we will still need majors.
3. (-) We embed magic UID and GID values in the kernel to make
/dev come up with the most sensible defaults.
4. (+) The devfs(8) facility allows people to override these
defaults in a race-free manner. In addition it allows the
user to define entirely new and wonderful policies.
Summary:
Don't expect changes in DEVFS, but do put pressure on driver
authors to get sensible defaults used.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
