fs changes in 2.3

2000-04-30 Thread Ani Joshi
hello, can someone point me to a rough list (if there is one) of all the things that need to be changed in each fs driver for 2.3? i'm not subscribed to this list so if this was posted before, please point me to a list archive if there is one. thanks, ani please CC me to any replies

Re: new VFS method sync_page and stacking

2000-04-30 Thread Erez Zadok
In message <[EMAIL PROTECTED]>, "Roman V. Shaposhnick" writes: > On Sun, Apr 30, 2000 at 03:28:18PM +0100, Steve Dodd wrote: [...] > > But an address_space is (or could be) a completely generic cache. It > > might never be associated with an inode, let alone a dentry or file > > structure. [...]

Re: new VFS method sync_page and stacking

2000-04-30 Thread Roman V. Shaposhnick
On Sun, Apr 30, 2000 at 03:28:18PM +0100, Steve Dodd wrote: > On Sun, Apr 30, 2000 at 01:44:50PM +0400, Roman V. Shaposhnick wrote: > > >Did you see my letter about readpage ? Nevertheless, I think that first > > argument of every function from address_space_operations should be > > "struct

Re: ext2 feature request

2000-04-30 Thread Andrew Clausen
Guest section DW wrote: > Let me partially contradict you. > DOS can handle 23 of these partitions. > In the above I did not necessarily mean "outer extended" - the > "inner extended" also work. Thus, as soon as something lives inside > the outer extended partition, that is, as soon as something i

Re: ext2 feature request

2000-04-30 Thread Guest section DW
On Sat, Apr 29, 2000 at 05:18:21PM +1000, Andrew Clausen wrote: > Guest section DW wrote: > > This type already exists - it is called extended partition. > > For each logical partition you can choose the offset yourself. > > (And never mind cylinder boundaries - geometry is out.) > > This won't w

Re: new VFS method sync_page and stacking

2000-04-30 Thread Erez Zadok
In message <[EMAIL PROTECTED]>, Steve Dodd writes: > On Sun, Apr 30, 2000 at 01:44:50PM +0400, Roman V. Shaposhnick wrote: > > >Did you see my letter about readpage ? Nevertheless, I think that first > > argument of every function from address_space_operations should be > > "struct file *" a

Multiple devfs mounts

2000-04-30 Thread Richard Gooch
Hi, Al. You've previously stated that you consider the multiple mount feature of devfs broken. I agree that there are some races in there. However, I'm not clear on whether you're saying that the entire concept is broken, or that it can be fixed with appropriate locking. I've asked this before,

Re: new VFS method sync_page and stacking

2000-04-30 Thread Steve Dodd
On Sun, Apr 30, 2000 at 01:44:50PM +0400, Roman V. Shaposhnick wrote: >Did you see my letter about readpage ? Nevertheless, I think that first > argument of every function from address_space_operations should be > "struct file *" and AFAIK this is 1) possible with the current kernel 2) will

Re: new VFS method sync_page and stacking

2000-04-30 Thread Erez Zadok
In message <[EMAIL PROTECTED]>, "Roman V. Shaposhnick" writes: > On Sun, Apr 30, 2000 at 04:46:37AM -0400, Erez Zadok wrote: > > Background: my stacking code for linux is minimal. I only stack on > > things I absolutely have to. By "stack on" I mean that I save a > > link/pointer to a lower-lev

Re: new VFS method sync_page and stacking

2000-04-30 Thread Roman V. Shaposhnick
On Sun, Apr 30, 2000 at 04:46:37AM -0400, Erez Zadok wrote: > Background: my stacking code for linux is minimal. I only stack on things I > absolutely have to. By "stack on" I mean that I save a link/pointer to a > lower-level object in the private data field of an upper-level object. I do > so

new VFS method sync_page and stacking

2000-04-30 Thread Erez Zadok
Background: my stacking code for linux is minimal. I only stack on things I absolutely have to. By "stack on" I mean that I save a link/pointer to a lower-level object in the private data field of an upper-level object. I do so for struct file, inode, dentry, etc. But I do NOT stack on pages.