> Here's a new patchkit to fix the dasd ioctl mess, against
> 2.6.16-rc2-mm1. I've built an s390 crosscompiler to compile-test them
and
> I've booted the resulting kernel with a debian image in hercules (not
that
> this excercises the ioctl path a whole lot, but I didn't find tools
that
> actually used any of these ioctls).
>
Thanks for doing some test this time.
If I got that right, there is no big difference related to your last
proposal.
Unfortunately neither me nor Stefan W. got an answer on the question
about being more precise on 'ioctl mess' or any other statements
like 'adds more junk to already crappy code'.
We can't see - and you did not specify - reasons why the current
approach does not work. Therefore I don't see any urgency to change
that NOW instead of discuss the design change (consulting Martin -
he will be back next week) and do the ioctl change when we have an
agreed solution including ALL components.
I agree that you proposal is straight forward and looks more pretty,
but I don't like the approach to just delete code that doesn't fit
your ideas.
As already mentioned we are currently working on a solution to move
the whole cmb-code out of the DASD device driver.
In addintion I talked to Stefan W. and he is doing some evalutation
about possible solution for the eer_module on how adapt that module
to your proposal while keeping the functionality.
As I already said, I would like to wait for final solution and
don't apply the patches NOW.
regards
Horst Hummel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
