Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 05 Jul 2002 05:06:06 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        "Vladimir B. Grebenschikov" <vova@sw.ru>
Cc:        Daniel O'Connor <doconnor@gsoft.com.au>, Bruce Evans <bde@zeta.org.au>, Greg 'groggy' Lehey <grog@FreeBSD.ORG>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Mario Goebbels <mariog@tomservo.cc>, "current@freebsd.org" <current@freebsd.org>
Subject:   Re: About DEVFS (was: Re: About GEOM...)
Message-ID:  <3D258BAE.3C77B9D9@mindspring.com>
References:  <20020704210304.Y21619-100000@gamplex.bde.org>  <3D24BB6E.3829314A@mindspring.com> <1025835014.4223.5.camel@chowder.gsoft.com.au>  <3D2506F9.8B34FD80@mindspring.com> <1025861904.810.3.camel@vbook.express.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
"Vladimir B. Grebenschikov" wrote:
> =F7 Fri, 05.07.2002, =D7 06:39, Terry Lambert =CE=C1=D0=C9=D3=C1=CC:
> > > Loader?
> > > ie on shutdown write a list of permissions etc into a file which th=
e
> > > loader can slurp up next boot and shove into the kernel and be pars=
ed.
> >
> > This really doesn't work very well.  You end up with two sets of
> > data.  Having done something like this in practice, and had to live
> > with the aftermath, I don't recommend it (at all).
> =

> May be same mechanism as hints, like:
> hint.sio.0.mode=3D0622
> =

> why not ? Symantic very similar (there are some kernel-hardcoded values=

> and some loader-supplied)

Because the proper order is:

	device arrival
	creation of device node
	...
	deletion of device node
	device departure

And you can't get that, unless you have software control of the
device eject mechanism -- and *only* software control (e.g. like
the Macintosh floppy drives); the closest you can get to this
with a PCMCIA device is to treat the removal notification you
get from the shorter pins no longer being connected as a
"highest priority" interrupt that invalidates the device, and
removed the node.  You're never going to get that with Bruce's
"devd" approach, which would need to depend on either *real*
RT scheduling to get rid of the device (not possible with PC
hardware, actually, since you can only guarantee one process at
RT, and then only with Djikstra's Banker's Algorithm), or on
letting invalid operations proceed to hard failure, with
recovery.  If you check the archives from two years ago, you
will see a long PCMCIA discussion, with the conclusion being a
reluctant admission that it's possible to do it right, but is
very difficult.  By going the "devd" route, you *guarantee*
that no one in the future can expend that effort, and make
things "work right".  See the archived discussion for more
details; there no reason to repeat it all again, particularly
since most of the very knowledgable PCMCIA people in that
discussion are no longer around.

-- Terry

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?3D258BAE.3C77B9D9>