Re: Request for comments (kdev_t and friends...)

Martin Dalecki (dalecki@cs.net.pl)
Fri, 26 Nov 1999 10:51:06 +0100

Alexander Viro wrote:
>
> On Fri, 26 Nov 1999, Martin Dalecki wrote:
>
> > 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.

Huh I didn't actually see this was remaining in my source tree.
I must have forgotten to take it out.

But since I'm basically using fat only for my zip drive, and there
just as a bag for file tranfer it is interresting that it still
didn't hurt me.

> 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...

Then just grep for 256 in the corresponsding file. It's terrible to
introduce just another array for every possible device...

--
	Marcin Dalecki


-
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/