Date: Wed, 2 Oct 2002 18:41:20 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Sheldon Hearn <sheldonh@starjuice.net>, <current@FreeBSD.ORG> Subject: Re: HEADSUP! GEOM as default in 5 days... Message-ID: <20021002180920.P4712-100000@gamplex.bde.org> In-Reply-To: <70347.1033543485@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 Oct 2002, Poul-Henning Kamp wrote:
> In message <20021002172300.V4620-100000@gamplex.bde.org>, Bruce Evans writes:
> >I don't really like MAKEDEV. It is creating work and bugs by moving
> >problems around that I object to.
>
> So you don't like DEVFS and you don't like MAKEDEV.
>
> Say, how _do_ you access your devices Bruce ? :-)
Mostly using read() and write() :-).
To create them I normally use tar or cp -pR to copy them from another
machine (nfs mounted for cp). Yes, major/minor numbers have their
weakest points near tar and nfs, but this causes few problems in
practice. To create the original versions I must have used mknod(8)
or MAKEDEV some time, but I only use these about once a month. Preserving
timestamps has given some amazingly old files (much older than the
disk they are on :-):
$ ls -ltr /dev
total 44
crw------- 1 root wheel 7, 0 Sep 14 1991 klog
crw-rw---- 2 root operator 14, 2 May 5 1993 esa0.0
...
crw-rw-rw- 1 root wheel 6, 10 Jun 11 1994 ptypa
...
crw-rw-rw- 1 root wheel 5, 10 Jun 11 1994 ttypa
klog is so old that it must have have a corrupt time stamp or have been
copied from a 386BSD distribution -- 386BSD wasn't released until early
1992 IIRC and I didn't get it until a few months later. Apparently,
Julian's scsi drivers were committed by May 5 1993. ttypa may be the
worlds oldest pty. I think it actually hasn't been touched since then.
Some of the other devices (not shown) are old because modtime timestamps
don't work right on them.
Ob devfs complaint: timestamps don't work right on devfs either. After
booting, ls -lt /dev and some periodic scripts report timestamps in
the future because devfs doesn't understand changing the time as
specified by /etc/wall_cmos_clock. This bug is more apparent to users
in timezones ahead of GMT.
> As various people have heard me whine about at conferences for some years
> now, devices were the first thing that broke the "UNIX filesystem model".
>
> Manually hacking a numeric index from a kernel table into filesystem
> nodes is just plain wrong, it is however better than what they did before
> where they hardwired inode numbers to devices.
This could have been done without devfs by mapping names of special files
to numeric indexes in the kernel. Putting the index in the inode is mainly
an efficiency hack. Numeric indexes work quite well in the kernel (better
than pointers in the current implementation, since most drivers prefer to
work with numbers and call the inefficient replacements of the major() and
minor macros a lot).
> The next big mistake was networking. The "unix filesystem model"
> would have me open("/net/tcp/www.freebsd.org/80", "r"), not
> socket(...), bind(...), connect(...).
I could agree with that.
> I'll just silently (well, not quite) pass on the sysV IPC fiasco.
The next+N mistake was sysctl, which started with numeric indexes and
which you improved to support strings. The indexes are worse than for
device nodes because they are layered. Supporting and using both of
these gave a fine unfinished mess, with complications for both and
efficiency for neither.
> In the meantime, DEVFS is the best I could come up with which makes
> life simpler for users, developers and administrators, and still
> retains as many of the flaws as we want to keep.
For me, it has saved about 10 minutes of admin time and cost a few
working weeks of development time so far.
> Like it or not, unless you have a better alternative you'll be stuck
> with it.
If it were the only alternative, then I would move somewhere that
doesn't have it :-).
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021002180920.P4712-100000>