Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 03 Nov 2003 16:43:45 +0100
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        Sam Leffler <sam@errno.com>
Cc:        cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/conf files src/sys/i386/i386 elan-mmcr.c 
Message-ID:  <31283.1067874225@critter.freebsd.dk>
In-Reply-To: Your message of "Mon, 03 Nov 2003 07:17:31 PST." <200311030717.31359.sam@errno.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <200311030717.31359.sam@errno.com>, Sam Leffler writes:
>On Monday 03 November 2003 03:03 am, Poul-Henning Kamp wrote:
>> phk         2003/11/03 03:03:40 PST
>>
>>   FreeBSD src repository
>>
>>   Modified files:
>>     sys/conf             files
>>     sys/i386/i386        elan-mmcr.c
>>   Log:
>>   Change /dev/soekris-errled to be /dev/led/error and make it conditional
>>   on CPU_SOEKRIS.
>
>I thought you were adamantly opposed to device subdirs?

I thought so too :-)

Now seriously...

I'm not adamantly against them, I just think they traditionally
have been misused terribly, and therefore I will not advocate
it as a general solution.

In this case I decided that the correct device name would be whatever
label the announciator has on the box, and since that can be anything,
"error", "disk", "floppy", "cdrom" or for that matter "console", I
wanted to make sure we would not have a name-clash.

Overall, I think my considered position is that "open namespaces"
shall be put in a subdir, volumenames ("/dev/vol/*") announciators
("/dev/led/*") are examples.

"Closed namespaces" ("/dev/pty%c%c") does not _have_ to, but given
good reason could be put in a subdir (beware of backwards compat).

Knowing how hard people are attached to the "good old BSD way", I'm
not going to be the one to push for a migration to /dev/disk/* for
instance.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31283.1067874225>