How do you deal with the
poll()
do stuff
poll()
and a directory chage occuring during a 'do stuff' period
> Currently all options suck equally. I'm not advocating /proc for the data
> (that'd be silly) but I am against a wholesale change from one dump to
> another in the name of being "pretty" wit a more significant fix.
It should be a misc device too obviously.
Your 68K of devfs does actually get
> Good grief Charley Brown! You, in a few key-strokes, just blew away
> major portions of the work done over the past few years by software
> engineers who ported their drivers to Linux. Linux will never be
> accepted as a 'professional' operating system if this continues.
Hardly. You obviously d
> What kind of work is this? If it's pretty simple stuff, just repetitive,
> I may be able to help out. Got an example of before/after? Or at least let me
It is fairly repetative
> know of a driver that has been 'properly' updated so I have something to work
> from? I'll try and look
> > Taking my working list the key items seem to be
> >
> Add "big usb urb patch that needs to go in" to the list.
Added. I'll put up a working list web page soon
> For less critical stuff (== near post-2.4.0):
> ->fhandle_to_dentry() (maybe it will go before the 2.4)
That one is pretty critical for NFS
> cleaning up remnants of dcache abuse in knfsd _and_ NFS.
> taking silly-rename mechanism into VFS (and smbfs might _really_
> win from
> loopback, ramdisk, raid - more or less broken.
Ingo has raid and PIII diff merging queued to do. The old raid code isnt worth
fixing on that basis.
> CODA - will need serious testing after the expected large patch.
CODA is the sort of thing that can be fixed up later.
> pro
> Some times ago I found a race in buffer code - many filesystems do
> getblk();mark_buffer_uptodate(); and then write to buffer. If the buffer
> is under read i/o, written data are lost.
Andrea certainly submitted me some 2.2.x patches for ext2fs for this that I
merged. I don't know how it stand
> It would be a blessing, especially if the journaling Ext2 or Reiserfs
> stuff was also folded into 2.4 as well. The lack of a LVM and a JFS have
> unfortunately kept any serious Linux use out of our shop for a while
> now.
I can see LVM getting into a standard kernel but not really ext3 (journ
> That said, we don't distrurb other folks's code, so why is it such an issue?
>
> I don't understand the comment about exporting half of the buffer cache into
> itself.
Because its not easy to prove you dont disturb other code. You make some stuff
global that wasnt for example.
> > There is al
> Because you might disturb other folks' _data_, if reiserfs goes wonky.
> It's easy to say "reiserfs is a bit too unproven for /home, but I'll
> happily put my squid cache onto it", without realising
I don't think anyone is going to accidentally type "mkreiserfs" thinking
mke2fs somehow. That on
> ways. I hope the proposal gets somewhere. Until it is done cleanly though, folks
> should be able to patch things as they must to make their code work. Don't you
> think?
Definitely. Thats the point of the License. For 2.2.13ac and 2.2.14pre Im trying
to ship stuff that is very heavily teste
> I disagree - I don't think that O_SYNC should imply writing back access
> and mtimes. If the file size really changes, that we definitely should
> write the inode back, I don't think we can honestly say that anything else
> would make sense..
SUS says this:
O_DSYNC
Write I/O opera
> As far as I can see, put_write_access() is sometimes called when no
> corresponding get_write_access() has been called, causing i_writecount
> to go negative.
>
> As far as I can see, this is in no way dangerous, it's just annoying
> when debugging. I think it should be given a look, though.
I
14 matches
Mail list logo
