atom feed32 messages in org.freebsd.freebsd-currentRe: Slice implementation (was: Curren...
FromSent OnAttachments
Alfred PerlsteinSep 23, 1998 1:38 am 
Jordan K. HubbardSep 23, 1998 2:29 am 
Alfred PerlsteinSep 23, 1998 3:42 am 
Peter WemmSep 23, 1998 4:24 am 
Jordan K. HubbardSep 23, 1998 4:35 am 
Bruce EvansSep 23, 1998 5:02 pm 
Terry LambertSep 23, 1998 6:03 pm 
David HollandSep 24, 1998 1:52 pm 
Archie CobbsSep 24, 1998 6:20 pm 
Bruce EvansSep 25, 1998 6:37 pm 
Poul-Henning KampSep 25, 1998 11:31 pm 
Justin T. GibbsSep 26, 1998 9:52 am 
Poul-Henning KampSep 26, 1998 10:32 am 
David HollandSep 26, 1998 7:45 pm 
David HollandSep 26, 1998 8:03 pm 
Poul-Henning KampSep 26, 1998 10:56 pm 
David HollandSep 26, 1998 11:59 pm 
Poul-Henning KampSep 27, 1998 12:21 am 
Greg LeheySep 27, 1998 1:11 am 
Greg LeheySep 27, 1998 1:26 am 
David HollandSep 27, 1998 1:32 am 
Terry LambertSep 27, 1998 1:58 pm 
Terry LambertSep 27, 1998 2:40 pm 
Jeremy LeaSep 28, 1998 7:19 am 
Eivind EklundSep 28, 1998 9:29 am 
Poul-Henning KampSep 28, 1998 10:49 am 
Julian ElischerSep 28, 1998 12:24 pm 
Larry S. LileSep 28, 1998 12:39 pm 
Poul-Henning KampSep 28, 1998 12:51 pm 
Larry S. LileSep 28, 1998 1:56 pm 
Terry LambertSep 28, 1998 4:47 pm 
David HollandSep 28, 1998 4:55 pm 
Subject:Re: Slice implementation (was: Current is Really Broken(tm))
From:Terry Lambert (tlam@primenet.com)
Date:Sep 27, 1998 2:40:05 pm
List:org.freebsd.freebsd-current

I can't see anything in this discussion which requires process context.

The I/O's to the disk to probe the SLICE driver format, and the allocation of a device descriptor for enqueueing the device arrival event for physical devices, which "arrive" by driver probe returning "true".

There is the need for, minimally, a kernel thread to field and process physical media arrival events.

I considered these options when writing Vinum, which is hairier than I want it to be. I decided against both of these alternatives, and for a third one: put it in an LKM. It's not going to work completely, because I need process context for I/O error recovery, but that's about the only thing.

If you need help on starting a kernel thread (process) in an LKM, I can give you info. The easiest thing to do is to look at the code in /sys/kern/init_main.c and see how the swapper, pagedaemon, vmdaemon, and update (or syncd) are started.

Tandem solved this problem decades ago: when you open a file, you specify an exclusion parameter, which can be "shared" (no exclusion), "protected" (anybody can read, only I can write), or "exclusive" (nobody else can access). There's also a parameter which specifies to wait until the file is available for access in the desired mode. This works very well. Applying the solution to UNIX is less a question of the implementation than of implementing it in a backwards-compatible manner.

O_EXLOCK, O_SHLOCK 8-).

But I would prefer to enforce a procedural interface instead of a data interface (i.e., use an ioctl() to manipulate the SLICE objects, instead of expecting the SLICE code to notice Joe Schmuck User writing disklabels on defenseless devices).

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message