From: Andries.Brouwer@cwi.nl
To: axboe@suse.de, dalecki@evision-ventures.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH][CFT] IDE TCQ #2
Date: Tue, 9 Apr 2002 15:34:34 GMT [thread overview]
Message-ID: <UTC200204091534.PAA574373.aeb@cwi.nl> (raw)
On Tue, Apr 09 2002, Martin Dalecki wrote:
> > echo "using_tcq:0" > /proc/ide/hdX/setting
> >
> > will disable TCQ and revert to DMA,
> >
> > echo "using_tcq:32" > /proc/ide/hdX/setting
> >
> > will set queue depth to 32, any value in between the two are of course
> > also allowed. The driver will print enable/disable info to the kernel
> > log.
>
> Well this belongs to an ioctl or sysctl... However most
> of the /proc/ide stuff if not all will go to the sysctl quite soon.
Put it wherever you want it, I'm just making it easier for myself not
having to pass patches to hdparm around as well for people to enable
taggged queueing.
Yes, for IDE purposes it does not matter much what one does.
But one needs communication between user or user space
and kernel to interact with hundreds of drivers, in a rather
messy way.
In my opinion sysctl() is worthless. It uses an array of numbers
where ioctl() uses a single number. Especially since the names are
already in the kernel it is much clearer and cleaner to use a
pathname. I wouldn't mind if sysctl() disappeared entirely.
Also ioctl() has its problems. First of all, nobody knows what the
prototype is. Secondly, it is too rigid - the moment one needs a
larger structure one needs a different ioctl.
A text based interface is much more flexible. If the number of
cylinders of a disk no longer fits in a short, well doesn't matter,
then the number of digits may increase but the interface remains
unchanged. Of course the price is that one has to parse, but
typically that is not a problem.
[Not that I want to revive old threads on this topic. This is
just a direct reaction to
> Well this belongs to an ioctl or sysctl... However most
> of the /proc/ide stuff if not all will go to the sysctl quite soon.
I do not think going to sysctl is an improvement.]
Andries
next reply other threads:[~2002-04-09 15:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-09 15:34 Andries.Brouwer [this message]
2002-04-09 15:22 ` [PATCH][CFT] IDE TCQ #2 Martin Dalecki
-- strict thread matches above, loose matches on Subject: below --
2002-04-09 16:38 Andries.Brouwer
2002-04-09 12:44 Jens Axboe
2002-04-09 12:24 ` Martin Dalecki
2002-04-09 13:41 ` Jens Axboe
2002-04-10 8:55 ` Martin Dalecki
2002-04-10 9:58 ` Jens Axboe
2002-04-10 9:04 ` Martin Dalecki
2002-04-10 10:09 ` Jens Axboe
2002-04-10 9:12 ` Martin Dalecki
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=UTC200204091534.PAA574373.aeb@cwi.nl \
--to=andries.brouwer@cwi.nl \
--cc=axboe@suse.de \
--cc=dalecki@evision-ventures.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