From: Elias Oltmanns <eo@nebensachen.de>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
greg@kroah.com, linux-kernel@vger.kernel.org
Subject: Re: Block: Trouble with kobject initialisation for blk_cmd_filter
Date: Tue, 09 Sep 2008 18:57:05 +0200 [thread overview]
Message-ID: <87prndp89q.fsf@denkblock.local> (raw)
In-Reply-To: <20080909131850.GL20055@kernel.dk> (Jens Axboe's message of "Tue, 9 Sep 2008 15:18:52 +0200")
Jens Axboe <jens.axboe@oracle.com> wrote:
> On Tue, Sep 09 2008, FUJITA Tomonori wrote:
[...]
>> The sysfs changes looks too much for 2.6.27-rcX but without the sysfs
>> changes, we have the cmdfilter under /sys/block/sda/queue/, right? We
>> don't need to worry about compatibility, but /sys/block/sda is more
>> appropriate? (though I don't think that the cmd filter is a good idea
>> so I don't care much).
>
> I agree, under sda/ makes a lot more sense than under sda/queue/
Well, but why is it in struct request_queue then? Is it going to be
moved back to the gendisk eventually?
>
>> Jens, would it be better to just disable the cmdfilter stuff for
>> 2.6.27? It's too late for another try to fix this broken stuff, I
>> guess.
>
> Yeah, it's certainly starting to look like it... The amount of changes
> to unbreak it are too large to submit now, so lets postpone it until
> 2.6.28.
I won't bother with the patch against 2.6.27-rc then. What about 2.6.28
though? Not that I really care whether the cmd_filter appears under sda/
or sda/queue/, I just wanted to point out that the sysfs code can be
simplified considerably. The things I do care about, of course, are the
two problems that have been fixed by my patch: There are no spurious
warnings and stack dumps due to kobject reinitialisation and the
cmd_filter sysfs interface inherits proper locking. Please take this
into consideration if you decide not to reuse the queue layer sysfs
interface. Otherwise, just let me know if you want me to port the patch
(just the cmd_filter part or the sysfs stuff as well) to next-200809..
Regards,
Elias
next prev parent reply other threads:[~2008-09-09 16:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-05 16:48 Block: Trouble with kobject initialisation for blk_cmd_filter Elias Oltmanns
2008-09-09 10:28 ` Jens Axboe
2008-09-09 12:45 ` FUJITA Tomonori
2008-09-09 13:18 ` Jens Axboe
2008-09-09 16:57 ` Elias Oltmanns [this message]
2008-09-10 2:43 ` FUJITA Tomonori
2008-09-15 19:55 ` Elias Oltmanns
2008-09-15 20:17 ` FUJITA Tomonori
2008-09-15 20:49 ` Elias Oltmanns
2008-09-15 21:31 ` FUJITA Tomonori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87prndp89q.fsf@denkblock.local \
--to=eo@nebensachen.de \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=greg@kroah.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox