Well I consider the sense decoding a somewhat important feature, hence
it's really bad it has been broken for months now. It's impossible to
diagnose problems in ide-cd code without it.
> >>- Eliminate block_ioctl(). This code can't be shared in the way
> >> proposed by this file. We will port it to the proper
> >> blk_insert_request() soon. This will eliminate the _elv_add_request()
> >> "layering violation".
> >What are you talking about?
> Hmm, so apparently you where not the one who "inventid" it?
? I added block_ioct.c, yes.
> Anyway I talk about the block_ioctl.c file, which was supposed
> to contain the two eject ioctl functions for "generic" packet code.
It _did_ contain two eject ioctl as a "here's what it's supposed to do"
proof of concept type thing.
> But since we don't have any kind of "generic" packet commands this
> didn't make much sense.
What are you talking about?!
> It was inventing a function called blk_do_rq(), which was using
> elv_add_request(). You called this not a long time ago a "layering
> violation" yourself. And I simply intend to replace it in one of the
> forthcomming patches with the recently inventid blk_insert_request()
Sigh... Martin, for fscks sake please stop always just assuming and get
your facts straight. This is why you are repeatedly pissing me (and
others) off. blk_do_rq() means "insert request and execute it, return
when it's done". It probably should have been in ll_rw_blk.c itself,
sinoce it's that sort of helper.
Using elv_add_request() is not a layering violation, that's the exported
interface... The layering violation is using __elv_add_request() since
it exposes the internal queue lists, which may not be appropriate for
all io schedulers.
> Oh, I realize I didn't express myself properly. I certinaly don't intend
> to eliminate elv_add_request() itself any time soon ;-).
No, I would appreciate it if you would keep your hands out of the block
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/