All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Jens Axboe <axboe@suse.de>
Cc: Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>,
	linux-ide@vger.kernel.org
Subject: Re: [BK PATCH] 2.6.x libata bug fix
Date: Tue, 26 Oct 2004 13:45:47 -0400	[thread overview]
Message-ID: <417E8D4B.8030203@pobox.com> (raw)
In-Reply-To: <20041026173025.GA15290@suse.de>

Jens Axboe wrote:
> On Tue, Oct 26 2004, Jeff Garzik wrote:
>>So, we return the proper return code, and ioctls we don't handle
>>start to work again.  Overall, though, this is a fragile way to do
>>things in the block layer, IMHO.
> 
> 
> Well, it's pretty much the universally accepted way of signalling this
> information, I'm not sure I agree. The crappy part is that EINVAL is so
> wide spread as well.


My point is that most Linux APIs don't apply default behavior by means 
of a magic return code.

Each block/scsi/etc. driver should provide their own ioctl handler as 
the highest-level callback.  Then, each individual driver decides its 
fallback strategy for unknown ioctls -- in most cases, by calling 
"libata_ioctl" or "scsi_ioctl" or "block_ioctl".

In this manner, ioctl handling cascades naturally up through the layers, 
without magic return codes.

The current "top-down" ioctl handling implementation leads to the 
current situation:  a bunch of ->ioctl() callsites scattered through the 
generic block ioctl handling code.

	Jeff



  reply	other threads:[~2004-10-26 17:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-26 16:02 [BK PATCH] 2.6.x libata bug fix Jeff Garzik
2004-10-26 17:30 ` Jens Axboe
2004-10-26 17:45   ` Jeff Garzik [this message]
2004-10-26 17:56     ` Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2004-10-27  0:00 Jeff Garzik

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=417E8D4B.8030203@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=akpm@osdl.org \
    --cc=axboe@suse.de \
    --cc=linux-ide@vger.kernel.org \
    --cc=torvalds@osdl.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.