> I Can't believe this email only produced TWO responses!
> I would have thought that this wouldhav brought out the chainsaws!
> Maybe no-one is listenning on 'arch' any more, or maybe 'arch' doesn't
> work? (the only responders got it via 'core')
Interesting. It appears that somehow I got 'unsubscribed' from arch.
Not sure why, but in May I was subscribed, but I'm no longer subscribed.
Did everyone get unsubscribed when it went idle?
(I'm not commenting on the content as I haven't done enough research to
agree/disagree with anything yet.)
Nate
>
> julian
>
> On Sat, 9 Oct 1999, Bruce Evans wrote:
>
> > > PHK has been moving steadily in this direction to remove as many
> > > dependencies within the kernel on block devices as possible.
> > > The question is, When did the decision to do so become official?
> >
> > Never.
> >
> > > I don't believe it has been a stated official decision yet and so in order
> > > to put some clarity into the air over this I'd like to launch a PURELY
> > > TECHNICAL discussion on the topic.
> > >
> > > Here are some starters.
> > >
> > > 1/ block device writes have to be synchrnous or the user doesn't get
> > > write errors.
> >
> > Block devices should be implmented properly or the user doesn't get write
> > errors.
> >
> > A proper implementation is quite close. Write errors should be reported
> > on last-close and on fsync(). They already are as far as I can see, modulo
> > the bugs that (in -current) VOP_FSYNC() = ffs_fsync() sometimes hangs
> > instead of returning a write error and vinvalbuf() sometimes panics instead
> > of returning a write error. The bugs are different and worse in RELENG_3.
> > The bugs are different and more benign in RELENG_2_2 (write errors are
> > ignored). Note that the bugs have very little to do with specfs. All
> > specfs can reasonably do is kill the endless retries at a suitable time,
> > probably after calling vinvalbuf() in last-close.
> >
> > > 1A/ if they are not synchronous, errors need to be coped with in some
> > > other manner.
> >
> > Normal error handling suffices, modulo bugs.
> >
> > > 2/ People with old UNIX experience expect to be able to do unalligned
> > > transfers on block devices.
> > > 3/ DEVFS can cope just fine with block and char devices
> > > (I include this because DEVFS has been used as an argument for
> > > removing them)
> >
> > Correct.
> >
> > > 4/ Most of the block buffering code in the kernel will remain due to
> > > the VM and VFS systems.
> >
> > Well, if the Nth rewrite of vm wants to drop support for buffers in vfs,
> > then use of buffers for block devices shouldn't stop it.
> >
> > > 5/ New users don't tend to understand the rather strange distinctions
> > > between BLK and CHR devices. Some people consider having both POLA and
> >
> > This is an argument for removing character (disk) devices, since most
> > new users will be from Linux where block (disk) devices were the only
> > ones available until recently. Block devices have always worked better
> > in Linux. E.g., media change is detected for floppies, and buffers
> > remain valid across last-close, until media change. The latter behaviour
> > can be not what is wanted (extra ioctls are needed to discard the buffers),
> > but it is often useful.
> >
> > > others consider having only one POLA. Linux had til just recently,
> > > only BLK disk devices. They just aded CHR disk devices but I don't
> > > know if they created a whole second calss of device to do so. (I doubt it)
> > > 6/ It should be possible to make an overlay device (similar to the way
> > > ccd works), that supplies buffered characteristics to a disk. This may
> > > be a different minor number or a differnt major number.. but be a CHR
> > > type device.
> >
> > This would involve needless duplicatication of half of the buffer cache
> > implementation (maybe the simple half) unless the buffer cache goes away.
> >
> > Bruce
> >
> >
>
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
