From: Roberto Nibali <ratz@drugphish.ch>
To: Martin Dalecki <dalecki@evision-ventures.com>
Cc: Andrew Morton <akpm@zip.com.au>, linux-kernel@vger.kernel.org
Subject: Re: Question about the ide related ioctl's BLK* in 2.5.7-pre1 kernel
Date: Thu, 14 Mar 2002 21:04:50 +0100 [thread overview]
Message-ID: <3C910262.6010107@drugphish.ch> (raw)
In-Reply-To: <3C9007F5.1000003@drugphish.ch> <3C900A11.55BA4B32@zip.com.au> <3C905894.90407@drugphish.ch> <3C905B9D.A1E3ACF6@zip.com.au> <3C9091D6.6030301@evision-ventures.com>
>>> AFAICS you only
>>> addressed the i386 arch with that patch, do you want the specific arch
>>> maintainers to clean up their part when your patch is finished?
>>>
>>
>> ? There's nothing arch-specific in any of this...
>
> And there is nothing IDE related either. The code removed
> at the time wasn't used!
I see. So the trick is to fix hdparm and tell it not to use ioctl(fd,
BLKRAGET, arg). But I don't think that the BIO changes introduce a means
for readahead control/export from/to user space? Or would this be
something like bio_ioctl(kdev_t, unsigned int, unsigned long), which is
actually not used anywhere, or the request queue approach used by Andrew
Morton?
The reason I was confused about the arch was that sparc64, ppc64,
mips64, s390x and x86_64 still provide a ioctl handler for those ioctl's
hooking up the the w_long (interestig naming concept btw) function.
Am I completely off the track here, mixing things up?
Best regards,
Roberto Nibali, ratz
next prev parent reply other threads:[~2002-03-14 20:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-14 2:16 Question about the ide related ioctl's BLK* in 2.5.7-pre1 kernel Roberto Nibali
2002-03-14 2:25 ` Andrew Morton
2002-03-14 8:00 ` Roberto Nibali
2002-03-14 8:13 ` Andrew Morton
2002-03-14 12:04 ` Martin Dalecki
2002-03-14 20:04 ` Roberto Nibali [this message]
2002-03-18 13:28 ` Martin Dalecki
2002-03-18 13:34 ` Jens Axboe
2002-03-18 13:43 ` Martin Dalecki
2002-03-18 13:51 ` Jens Axboe
2002-03-14 12:12 ` Martin Dalecki
2002-03-14 12:43 ` Jeff Garzik
2002-03-14 12:51 ` Martin Dalecki
2002-03-14 17:38 ` Andrew Morton
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=3C910262.6010107@drugphish.ch \
--to=ratz@drugphish.ch \
--cc=akpm@zip.com.au \
--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 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.