All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Dalecki <dalecki@evision-ventures.com>
To: Andries.Brouwer@cwi.nl
Cc: axboe@suse.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][CFT] IDE TCQ #2
Date: Tue, 09 Apr 2002 17:22:05 +0200	[thread overview]
Message-ID: <3CB3071D.9000005@evision-ventures.com> (raw)
In-Reply-To: <UTC200204091534.PAA574373.aeb@cwi.nl>

Andries.Brouwer@cwi.nl wrote:
>     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.

Please have a look at /proc/sys/ OK?

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


  reply	other threads:[~2002-04-09 16:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-09 15:34 [PATCH][CFT] IDE TCQ #2 Andries.Brouwer
2002-04-09 15:22 ` Martin Dalecki [this message]
  -- 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=3CB3071D.9000005@evision-ventures.com \
    --to=dalecki@evision-ventures.com \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=axboe@suse.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.