From owner-freebsd-fs Mon Sep 23 06:05:40 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA07021 for fs-outgoing; Mon, 23 Sep 1996 06:05:40 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA06964; Mon, 23 Sep 1996 06:05:33 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id OAA16765; Mon, 23 Sep 1996 14:05:24 +0100 Date: Mon, 23 Sep 1996 14:05:23 +0100 (BST) From: Doug Rabson To: fs@freebsd.org, lite2@freebsd.org Subject: New d_type field in *devsw Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk What use is [bc]devsw->d_type in Lite2? It is not used anywhere and having it means changing *every* driver in the system since the initialiser for [bc]devsw is different. I would quite like to keep [bc]devsw the same as before the lite2 merge to keep compatability with existing drivers. What do others think? -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426 From owner-freebsd-fs Mon Sep 23 06:52:41 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA01956 for fs-outgoing; Mon, 23 Sep 1996 06:52:41 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA01804; Mon, 23 Sep 1996 06:52:24 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id OAA16992; Mon, 23 Sep 1996 14:51:49 +0100 Date: Mon, 23 Sep 1996 14:51:49 +0100 (BST) From: Doug Rabson To: fs@freebsd.org, lite2@freebsd.org Subject: vnode_pager_uncache() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I want to add a struct proc* argument to this call. The reason is that lite2 has a struct proc* argument to vn_lock/VOP_UNLOCK and panics if the wrong process unlocks a vnode. This causes trouble for the odd cases like shutdown where a process other than curproc is given to the filesystem since vnode_pager_uncache needs to manipulate the vnode lock sometimes. I can hack around it by ignoring the passed proc and substituting curproc in the places which matter but the right thing to do is for vnode_pager_uncache to use the correct proc. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426 From owner-freebsd-fs Mon Sep 23 07:28:38 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA17295 for fs-outgoing; Mon, 23 Sep 1996 07:28:38 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA17260; Mon, 23 Sep 1996 07:28:34 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id JAA11836; Mon, 23 Sep 1996 09:24:46 -0500 (EST) From: "John S. Dyson" Message-Id: <199609231424.JAA11836@dyson.iquest.net> Subject: Re: vnode_pager_uncache() To: dfr@render.com (Doug Rabson) Date: Mon, 23 Sep 1996 09:24:46 -0500 (EST) Cc: fs@freebsd.org, lite2@freebsd.org In-Reply-To: from "Doug Rabson" at Sep 23, 96 02:51:49 pm Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I want to add a struct proc* argument to this call. The reason is that > lite2 has a struct proc* argument to vn_lock/VOP_UNLOCK and panics if the > wrong process unlocks a vnode. This causes trouble for the odd cases like > shutdown where a process other than curproc is given to the filesystem > since vnode_pager_uncache needs to manipulate the vnode lock sometimes. > > I can hack around it by ignoring the passed proc and substituting curproc > in the places which matter but the right thing to do is for > vnode_pager_uncache to use the correct proc. > Sounds okay. Continue in that direction, and later on after work, I'll review it more carefully. (in a hurry to go to work :-)). John From owner-freebsd-fs Mon Sep 23 08:26:55 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA07071 for fs-outgoing; Mon, 23 Sep 1996 08:26:55 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA07025; Mon, 23 Sep 1996 08:26:43 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id BAA23463; Tue, 24 Sep 1996 01:20:36 +1000 Date: Tue, 24 Sep 1996 01:20:36 +1000 From: Bruce Evans Message-Id: <199609231520.BAA23463@godzilla.zeta.org.au> To: dfr@render.com, fs@FreeBSD.ORG, lite2@FreeBSD.ORG Subject: Re: New d_type field in *devsw Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >What use is [bc]devsw->d_type in Lite2? It is not used anywhere and >having it means changing *every* driver in the system since the >initialiser for [bc]devsw is different. I would quite like to keep >[bc]devsw the same as before the lite2 merge to keep compatability with >existing drivers. What do others think? Yes, don't change it. It probably needs to be done in another way for devfs. Bruce From owner-freebsd-fs Mon Sep 23 08:59:07 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA18960 for fs-outgoing; Mon, 23 Sep 1996 08:59:07 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA18935 for ; Mon, 23 Sep 1996 08:58:57 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id BAA24393 for fs@freebsd.org; Tue, 24 Sep 1996 01:56:37 +1000 Date: Tue, 24 Sep 1996 01:56:37 +1000 From: Bruce Evans Message-Id: <199609231556.BAA24393@godzilla.zeta.org.au> To: fs@FreeBSD.org Subject: untangling dirent macros Sender: owner-fs@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I found that cd96660_vnops.c and devfs_vnops.c use the deprecated compatibility header . Several other places include it but don't actually use it. attempts to include the application header , but because of the bogus -I$S/sys in the kernel Makefile, it actually includes . This works because kernel sources really want anyway. When I removed -I$S/sys, started including the application header. This worked too. cd96660_vnops.c and devfs_vnops.c only need the DIRSIZ() macro from . ufs avoids by having its own copy of the macro in , where the macro describes the on-disk layout. The on-disk layout happens to be suitable for returning almost directly in ufs_readdir(), at least on 32-bit machines (I think there might be alignment problems for future(?) 64-bit machines). I think a version of the macro that gives minimal padding of the name for readdir() should be defined in and all the names should be unique. Maybe rename the ufs version UFS_DIRSIZ(). Maybe is required to sometimes specify 64-bit alignment. There is a similar problem with DIRBLKSIZE. It is defined as 1024 in , but the kernel normally never sees or uses that. ufs uses DEV_BSIZE=512. nfs_serv.c and nfs_vnops.c include so that they can misuse the ufs value. ext2fs_lookup.c includes so that it can misuse the ufs value and lots more ufs stuff. I think a generic value for this should be defined in . Bruce From owner-freebsd-fs Mon Sep 23 13:41:21 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA10852 for fs-outgoing; Mon, 23 Sep 1996 13:41:21 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA10806; Mon, 23 Sep 1996 13:41:17 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.6/CET-v2.1) with SMTP id UAA16983; Mon, 23 Sep 1996 20:40:19 GMT Date: Tue, 24 Sep 1996 05:40:19 +0900 (JST) From: Michael Hancock To: Bruce Evans cc: dfr@render.com, fs@FreeBSD.ORG, lite2@FreeBSD.ORG Subject: Re: New d_type field in *devsw In-Reply-To: <199609231520.BAA23463@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 24 Sep 1996, Bruce Evans wrote: > >What use is [bc]devsw->d_type in Lite2? It is not used anywhere and > >having it means changing *every* driver in the system since the > >initialiser for [bc]devsw is different. I would quite like to keep > >[bc]devsw the same as before the lite2 merge to keep compatability with > >existing drivers. What do others think? > > Yes, don't change it. It probably needs to be done in another way for > devfs. But what is it? Is it 'c' or 'b', redundant with the two device switches, and needed for abstractions that don't want to discriminate using the name? Regards, Mike Hancock From owner-freebsd-fs Tue Sep 24 01:53:55 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA25675 for fs-outgoing; Tue, 24 Sep 1996 01:53:55 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA25647 for ; Tue, 24 Sep 1996 01:53:48 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.6/CET-v2.1) with SMTP id IAA21618; Tue, 24 Sep 1996 08:53:27 GMT Date: Tue, 24 Sep 1996 17:53:27 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: "Hr.Ladavac" cc: fs@FreeBSD.ORG Subject: Re: Transitive Closure--a Question for Terry In-Reply-To: <199609101109.AA067513751@ws2301.gud.siemens.co.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It summarizes information in a directed graph. There's a description in "Algorithms in C" by Robert Sedgewick. The book is also a good reference if you want to look at radix tries which are used in couple places in 4.4BSD. Regards, Mike Hancock On Tue, 10 Sep 1996, Hr.Ladavac wrote: > Hi all, especially Terry. > > The term "Transitive Closure" and its calculation has been > repeatedly mentioned in this forum (list, whatever.) > > My personal question is what does it mean to you. To be > honest, I've never stumbled upon the term before, and the > fact that the graph theory textbooks I read were in Russian > is probably no help either. > > My gut tells me it has to do with cycle detection/prevention > in a directed graph, but I cannot be sure. > > If so, the obvious algorithms to use are very simple, albeit > not deterministic in time, with the worst case of O(N**2) > IIRC. > > /Marino > From owner-freebsd-fs Tue Sep 24 04:48:52 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA26936 for fs-outgoing; Tue, 24 Sep 1996 04:48:52 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA26768; Tue, 24 Sep 1996 04:48:35 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id MAA20029; Tue, 24 Sep 1996 12:45:43 +0100 Date: Tue, 24 Sep 1996 12:45:42 +0100 (BST) From: Doug Rabson To: Michael Hancock cc: Bruce Evans , fs@FreeBSD.ORG, lite2@FreeBSD.ORG Subject: Re: New d_type field in *devsw In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 24 Sep 1996, Michael Hancock wrote: > On Tue, 24 Sep 1996, Bruce Evans wrote: > > > >What use is [bc]devsw->d_type in Lite2? It is not used anywhere and > > >having it means changing *every* driver in the system since the > > >initialiser for [bc]devsw is different. I would quite like to keep > > >[bc]devsw the same as before the lite2 merge to keep compatability with > > >existing drivers. What do others think? > > > > Yes, don't change it. It probably needs to be done in another way for > > devfs. > > But what is it? Is it 'c' or 'b', redundant with the two device switches, > and needed for abstractions that don't want to discriminate using the > name? I looked into this in a bit more detail today. In lite2, bdevsw->d_type is used to implement the securelevel for disks and to add some kind of generic ioctl for tapes. cdevsw->d_type is used for ttys to change the behaviour of dead_read. In FreeBSD, dead_read returns EOF for character devices and EIO for block devices.. In Lite2, it returns EOF only for ttys. There is an existing unused field in bdevsw, d_flags which can be used to identify disks and tapes for securelevel and ioctl or alternatively the existing FreeBSD behaviour of calling isdisk() is still possible. The current behaviour of dead_read is probably also adequate. Needless to say, these hacks should be first against the wall after the devfs revolution :-). -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426 From owner-freebsd-fs Tue Sep 24 10:24:32 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA07981 for fs-outgoing; Tue, 24 Sep 1996 10:24:32 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA07899; Tue, 24 Sep 1996 10:24:20 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id DAA07851; Wed, 25 Sep 1996 03:19:24 +1000 Date: Wed, 25 Sep 1996 03:19:24 +1000 From: Bruce Evans Message-Id: <199609241719.DAA07851@godzilla.zeta.org.au> To: dfr@render.com, michaelh@cet.co.jp Subject: Re: New d_type field in *devsw Cc: bde@zeta.org.au, fs@FreeBSD.org, lite2@FreeBSD.org Sender: owner-fs@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >There is an existing unused field in bdevsw, d_flags which can be used to >identify disks and tapes for securelevel and ioctl or alternatively the >existing FreeBSD behaviour of calling isdisk() is still possible. The >current behaviour of dead_read is probably also adequate. >Needless to say, these hacks should be first against the wall after the >devfs revolution :-). They are high quality compared with isdisk(). The cross pointers in the devsw's can be be used to share d_flags with the cdevs. However, to use them we would have to modify a lot of device drivers with a temporary change. Bruce From owner-freebsd-fs Tue Sep 24 10:58:22 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA18441 for fs-outgoing; Tue, 24 Sep 1996 10:58:22 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA18170; Tue, 24 Sep 1996 10:57:31 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id SAA20849; Tue, 24 Sep 1996 18:54:47 +0100 Date: Tue, 24 Sep 1996 18:54:46 +0100 (BST) From: Doug Rabson To: Bruce Evans cc: michaelh@cet.co.jp, fs@FreeBSD.org, lite2@FreeBSD.org Subject: Re: New d_type field in *devsw In-Reply-To: <199609241719.DAA07851@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 25 Sep 1996, Bruce Evans wrote: > >There is an existing unused field in bdevsw, d_flags which can be used to > >identify disks and tapes for securelevel and ioctl or alternatively the > >existing FreeBSD behaviour of calling isdisk() is still possible. The > >current behaviour of dead_read is probably also adequate. > > >Needless to say, these hacks should be first against the wall after the > >devfs revolution :-). > > They are high quality compared with isdisk(). My current hack derives the correct value for d_flags at initialisation time from isdisk :-). Not ideal. > > The cross pointers in the devsw's can be be used to share d_flags with > the cdevs. However, to use them we would have to modify a lot of > device drivers with a temporary change. Except for ttys which don't have a bdevsw. Still, I think the existing FreeBSD behaviour is almost OK there. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426