> The attached patch is basically showing the full impact of any attempt
> to
> enhance the kdev_t struct handling inside the current linux kernel.
> Of course it isn't intended to be applyed to any kind of "production
> system".
> It is taking the pants off from many *many* of the places where there
> are fundamental flaws in the current design :-(. Really indeed it's all
> looking very scary...
>
> However this is something that has to be done anyway. Better sooner then
> later.
> (In fact I get somehow the feeling that it's already too late.)
>
> I hope that people responsible for the particular pieces will take it
> as documentation for where there is a strong need for cleanup.
> In esp. for example the serial driver and the block hash should
> be cleaned up immediately.
Several comments:
a) fs/fat/file.c. WTF? If you see that two pieces of code have
something in common - take the fscking pain to compare and understand what
the hell happens _before_ (and in this case - instead of) dropping one of
them. It had been discussed on l-k. Several times. FAT does not allow
holes in files. By (b0rken) design. We can't use buffer cache to zero out
the missing piece, since it can merrily go into pagecache immediately
after that. We _have_ to allocate and zero said piece. We _can't_ do it
from ->getblock(), due to all sorts of interesting locking problems. We
can do it from ->write() and we can do it from write_one_page if we use
generic_file_write(). IOW, there is a very good reason (see above) why we
can't use the block_write_partial_page(). Wish we could.
b) if ->read_super() fails it tells about that fact. No need to
scare sheep^W^Wzero s->dev in foo_read_super() - fs/super.c::read_super()
will do it just fine.
c) check for ->i_dev in fs/ext2/ialloc.c and friends is pure
hogwash. It _really_ can't happen.
d) diff has a nice option: -b. It _really_ helps.
> I'm open to any kind of suggestions.
Any? cmsg newgroup alt.linux-kernel.recovery. BTW, I'm serious -
it would make sense.
> Whoever sponsored the RAW device implementation could have as well
> burned the
> money... This is once again a half done solution on top of a basically
> flawed ground,
> which is just adding unneccesary complexity to a poper resolution of
> the involved issues.
I don't think that SCT is _that_ easy to troll...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/