Date: Wed, 18 Apr 2001 14:09:46 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Julian Elischer <julian@elischer.org> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Matt Dillon <dillon@earth.backplane.com>, Kirk McKusick <mckusick@mckusick.com>, Rik van Riel <riel@conectiva.com.br>, freebsd-hackers@FreeBSD.ORG, David Xu <bsddiy@21cn.com> Subject: Re: vm balance Message-ID: <Pine.NEB.3.96L.1010418140218.2462N-100000@fledge.watson.org> In-Reply-To: <3ADDD553.46BF216D@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 18 Apr 2001, Julian Elischer wrote: > Poul-Henning Kamp wrote: > > > > In message <200104181702.f3IH24s23282@earth.backplane.com>, Matt Dillon writes: > > > If this will get rid of or clean up the specfs garbage, then I'm all > > > for it. I would love to see a 'clean' fileops based device interface. > > > > specfs, aliased vnodes, you name it... > > > > I think the aliased vnodes is the single most strong argument of them > > all for doing this... > > Great. Then we have aliased file pointers... that's not a great > improvement.. > > You'd still have to have 'per instance' storage somewhere, so that the > openned devices could have different permissions, and still have them > point to common data. so you still need aliases, except now it's not a > vnode being aliased but some other structure. As I justed stated in a private e-mail to Matt, I'm not opposed to the idea of promoting devices to a first-class object (i.e., equivilent to vnodes, rather than below vnodes) in FreeBSD, I just want to approach this very cautiously, as there's a lot of obscure behavior in this area, and a lot of portability concerns regarding the obscure behavior. In particular, the "special case" of ttys is a very important special case -- operations such as revoke() must continue to work. With device operations currently being pushed through VFS, VFS becomes a possible mediation point for those operations, allowing "VFS magic" to be used on devices. If we remove VFS from the call stack, we lose that capability. Poul-Henning has successfully argued that this has a number of good implications, but we need to make sure that the functionality lost there doesn't out-weight the good bits. One way to look at this disagreement might be the following: some people feel that devices are simply evil, and not files, and shouldn't try to act like them. Others feel that, modulo ioctl, we really can make devices look like files, and should do that. The observation I tried to make in an earlier e-mail was that it might be possible to accept the world-view that "devices aren't files" by mapping some devices into a better abstraction, such as the socket "data stream" concept, while still making use of current abstractions. For example, using read() on /dev/audit sucks, since what comes out of /dev/audit is a set of discrete records. I'd rather use recv(), which has far superior semantics, since this is a record-oriented data stream. The same goes for kernel log messages, which on a discrete message-oriented stream could essentially become standard syslog messages, rather than treating it as a text buffer with character pointers. This would allow wrap-around to be handled much more cleanly, by simply dropping records off one end of the record chain, rather than severing lines and ending up with the current /dev/console abomination (send too much to /dev/console -- i.e., single user mode, and dmesg becomes useless). I won't claim that moving to the slightly more abstracted viewpoint I proposed earlier is the way to go, just that it's worth keeping in mind. Maybe we should just throw up our hands and say "devices are devices, screw files" -- this decision was made with NFS, and dramatically simplifies the problem space. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010418140218.2462N-100000>