Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Apr 2001 16:54:52 +0200
From:      Poul-Henning Kamp <phk@critter.freebsd.dk>
To:        Robert Watson <rwatson@FreeBSD.ORG>
Cc:        Kirk McKusick <mckusick@mckusick.com>, Julian Elischer <julian@elischer.org>, Rik van Riel <riel@conectiva.com.br>, freebsd-hackers@FreeBSD.ORG, Matt Dillon <dillon@earth.backplane.com>, David Xu <bsddiy@21cn.com>
Subject:   Re: vm balance 
Message-ID:  <38778.987605692@critter>
In-Reply-To: Your message of "Wed, 18 Apr 2001 09:52:25 EDT." <Pine.NEB.3.96L.1010418094428.2462A-100000@fledge.watson.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.NEB.3.96L.1010418094428.2462A-100000@fledge.watson.org>, Rober
t Watson writes:
>
>On Wed, 18 Apr 2001, Poul-Henning Kamp wrote:
>
>> In message <200104180540.WAA58303@beastie.mckusick.com>, Kirk McKusick writes:
>> 
>> >Every vnode in the system has an associated object. 
>> 
>> No: device vnodes dont...
>> 
>> I think the correct solution to that is to move devices away from vnodes
>> and into the fdesc layer, just like fifo's and sockets. 
>
>I dislike that idea for a number of reasons, not least of which is that
>introducing more and more file-descriptor level objects increases the
>complexity of the system call service implementation, and duplicates code.
>If we're going to pretend that everything in the system is a file, and
>most people seem willing to accept that, acting on devices through vnodes
>seems like a reasonable choice.

I have not examined the full details of doing the shift yet, but it is
my impression that it actually will reduce the amount of code 
duplication and special casing.

Basically we will need a new:

	struct fileops devfileops = {
		dev_read,
		dev_write,,
		dev_ioctl,
		dev_poll,
		dev_kqfilter,
		dev_stat,
		dev_close
	};

The only places we will need new magic is
	open, which needs to fix the plumbing for us.
	mmap, which may have to be added to the fileops vector.

The amount of special-casing code this would remove from the vnode
layer is rather astonishing.

If we merger vm-objects and vnodes without taking devices out of the
mix, we will need even more special-case code for devices.

>The vnode is our abstraction for objects that have
>address spaces, can be opened/closed and retain a seeking position, can be
>mapped, have protections, etc, etc.

This is simply not correct Robert, UNIX::sockets also have many of
those properties, but they're not vnodes...

>Besides which,
>the kernel knows how to act on vnodes, and there is plenty of precedent
>for the kernel opening vnodes and keeping around references for its own
>ends, but there isn't all that much precedent for the kernel doing this
>using file descriptors :-).

Have you actually examined how FIFO and Sockets work Robert ?   :-)

--
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.

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?38778.987605692>