linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: alan@lxorguk.ukuu.org.uk
Cc: manik@cisco.com, linux-kernel@vger.kernel.org
Subject: Re: ioctl conflicts
Date: Thu, 30 Aug 2001 02:29:17 -0700 (PDT)	[thread overview]
Message-ID: <20010830.022917.52165205.davem@redhat.com> (raw)
In-Reply-To: <E15cNuP-0000mP-00@the-village.bc.nu>
In-Reply-To: <20010830.013023.94071732.davem@redhat.com> <E15cNuP-0000mP-00@the-village.bc.nu>

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Thu, 30 Aug 2001 10:14:45 +0100 (BST)

   >    Thats fine. ext2 ioctls and video ioctls go to different places
   > Consider sparc64.
   
   If the ioctl translation layer can't handle duplicates it has bigger
   problems than that

How else can the current scheme translate arguments correctly
if the ioctl values are identical?

Let's say that the video info struct is two ints, right?
That would make the two ioctl values in question be identical.

I agree whole-heartedly that the current scheme is flawed, what
really should happen is that the translations occur in the ioctl
handlers themselves, not in some funny sparc port sources.

That is something I will be doing in 2.5.x, for sure.

Later,
David S. Miller
davem@redhat.com

  parent reply	other threads:[~2001-08-30  9:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-28 12:53 Size of pointers in sys_call_table? Harald Barth
2001-08-28 13:26 ` Brian Gerst
2001-08-28 14:30   ` Harald Barth
2001-08-28 16:17   ` Alan Cox
2001-08-29  0:49     ` Keith Owens
2001-08-29 23:26     ` Ralf Baechle
2001-08-30  7:47 ` ioctl conflicts Manik Raina
2001-08-30  8:16   ` Gerd Knorr
2001-08-30  9:34     ` Manik Raina
2001-08-30  8:20   ` Alan Cox
2001-08-30  9:15     ` Andreas Dilger
2001-09-03  1:06     ` Wichert Akkerman
2001-08-30  8:30   ` David S. Miller
2001-08-30  9:00     ` Andreas Schwab
2001-08-30  9:14     ` Alan Cox
2001-08-30  9:29     ` David S. Miller [this message]
2001-08-30  9:31   ` David S. Miller

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=20010830.022917.52165205.davem@redhat.com \
    --to=davem@redhat.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manik@cisco.com \
    /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;
as well as URLs for NNTP newsgroup(s).