All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurentp@cse-semaphore.com>
To: linux-mtd@lists.infradead.org, dedekind@infradead.org
Cc: v4l-dvb-maintainer@linuxtv.org,
	LKML <linux-kernel@vger.kernel.org>,
	arnd@arndb.de
Subject: Re: UBI/DVB ioctl conflict?
Date: Mon, 8 Dec 2008 10:41:13 +0100	[thread overview]
Message-ID: <200812081041.14178.laurentp@cse-semaphore.com> (raw)
In-Reply-To: <1228717226.13686.89.camel@sauron>

Hi,

On Monday 08 December 2008 07:20:26 Artem Bityutskiy wrote:
> On Sun, 2008-12-07 at 09:58 -0500, Josh Boyer wrote:
> > I received a bug report where someone noticed that the UBI ioctls can
> > conflict with the dvb subsystem.  Looking it over, it seems that both
> > subsystems use 'o' as the magic, and do have a set of somewhat
> > conflicting sequence numbers as the secondary arg.
> >
> > Is this a problem?
>
> Hmm, thanks for noticing.
>
> I've looked at this, and thankfully it looks like we were lucky and do
> not use the same 'ioctl()' numbers, by chance.
>
> Ioctl number has the following structure:
>
> bits 0-15: command (or sequence number)
> bits 16-29: parameter size
> bits 30-31: mode (read, write, etc).
>
> We have the following overlaps with DVB subsystem:
>
> #define AUDIO_STOP   _IO('o', 1)
> #define UBI_IOCRMVOL _IOW('o', 1, int32_t)
>
> #define AUDIO_PLAY   _IO('o', 2)
> #define UBI_IOCRSVOL _IOW('o', 2, struct ubi_rsvol_req)
>
> #define AUDIO_PAUSE  _IO('o', 3)
> #define UBI_IOCRNVOL _IOW('o', 3, struct ubi_rnvol_req)
>
> These are fine because parameter sizes are different, and because UBI
> uses _IOW and DVB uses _IO, so the mode bits are "01" and "00".
>
> And:
>
> #define FE_DISEQC_RECV_SLAVE_REPLY _IOR('o', 64,
>                                         struct dvb_diseqc_slave_reply)
> #define UBI_IOCATT _IOW('o', 64, struct ubi_attach_req)
>
> #define FE_DISEQC_SEND_BURST _IO('o', 65)
> #define UBI_IOCDET _IOW('o', 65, int32_t)
>
> are also fine because parameter sizes are different and the mode bits
> are different.
>
> However, we have to be very careful in the future. It seems like DVB
> has been in the kernel long before UBI, so this potential conflict
> would be my fault.
>
> Neither DVB nor UBI seem not to be documented in
> Documentation/ioctl/ioctl-number.txt. Should we do this?
>
> P.S. Added Arnd to CC for suggestions, as well as LKML and DVB
> maintainers.

Correct me if I'm wrong, but doesn't this only matters for devices that would 
implement both the UBI and DVB API on the same inode ? That would be quite 
unlikely.

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurentp@cse-semaphore.com>
To: linux-mtd@lists.infradead.org, dedekind@infradead.org
Cc: Josh Boyer <jwboyer@linux.vnet.ibm.com>,
	v4l-dvb-maintainer@linuxtv.org,
	LKML <linux-kernel@vger.kernel.org>,
	arnd@arndb.de
Subject: Re: UBI/DVB ioctl conflict?
Date: Mon, 8 Dec 2008 10:41:13 +0100	[thread overview]
Message-ID: <200812081041.14178.laurentp@cse-semaphore.com> (raw)
In-Reply-To: <1228717226.13686.89.camel@sauron>

Hi,

On Monday 08 December 2008 07:20:26 Artem Bityutskiy wrote:
> On Sun, 2008-12-07 at 09:58 -0500, Josh Boyer wrote:
> > I received a bug report where someone noticed that the UBI ioctls can
> > conflict with the dvb subsystem.  Looking it over, it seems that both
> > subsystems use 'o' as the magic, and do have a set of somewhat
> > conflicting sequence numbers as the secondary arg.
> >
> > Is this a problem?
>
> Hmm, thanks for noticing.
>
> I've looked at this, and thankfully it looks like we were lucky and do
> not use the same 'ioctl()' numbers, by chance.
>
> Ioctl number has the following structure:
>
> bits 0-15: command (or sequence number)
> bits 16-29: parameter size
> bits 30-31: mode (read, write, etc).
>
> We have the following overlaps with DVB subsystem:
>
> #define AUDIO_STOP   _IO('o', 1)
> #define UBI_IOCRMVOL _IOW('o', 1, int32_t)
>
> #define AUDIO_PLAY   _IO('o', 2)
> #define UBI_IOCRSVOL _IOW('o', 2, struct ubi_rsvol_req)
>
> #define AUDIO_PAUSE  _IO('o', 3)
> #define UBI_IOCRNVOL _IOW('o', 3, struct ubi_rnvol_req)
>
> These are fine because parameter sizes are different, and because UBI
> uses _IOW and DVB uses _IO, so the mode bits are "01" and "00".
>
> And:
>
> #define FE_DISEQC_RECV_SLAVE_REPLY _IOR('o', 64,
>                                         struct dvb_diseqc_slave_reply)
> #define UBI_IOCATT _IOW('o', 64, struct ubi_attach_req)
>
> #define FE_DISEQC_SEND_BURST _IO('o', 65)
> #define UBI_IOCDET _IOW('o', 65, int32_t)
>
> are also fine because parameter sizes are different and the mode bits
> are different.
>
> However, we have to be very careful in the future. It seems like DVB
> has been in the kernel long before UBI, so this potential conflict
> would be my fault.
>
> Neither DVB nor UBI seem not to be documented in
> Documentation/ioctl/ioctl-number.txt. Should we do this?
>
> P.S. Added Arnd to CC for suggestions, as well as LKML and DVB
> maintainers.

Correct me if I'm wrong, but doesn't this only matters for devices that would 
implement both the UBI and DVB API on the same inode ? That would be quite 
unlikely.

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

  reply	other threads:[~2008-12-08  9:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-07 14:58 UBI/DVB ioctl conflict? Josh Boyer
2008-12-08  6:20 ` Artem Bityutskiy
2008-12-08  6:20   ` Artem Bityutskiy
2008-12-08  9:41   ` Laurent Pinchart [this message]
2008-12-08  9:41     ` Laurent Pinchart
2008-12-08  9:51     ` Artem Bityutskiy
2008-12-08  9:51       ` Artem Bityutskiy
2008-12-08 15:50       ` Arnd Bergmann
2008-12-08 15:50         ` Arnd Bergmann
2008-12-08 16:33         ` Artem Bityutskiy
2008-12-08 16:33           ` Artem Bityutskiy
2008-12-08 20:30           ` Arnd Bergmann
2008-12-08 20:30             ` Arnd Bergmann
2008-12-08 13:31     ` Jamie Lokier
2008-12-08 13:31       ` Jamie Lokier

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=200812081041.14178.laurentp@cse-semaphore.com \
    --to=laurentp@cse-semaphore.com \
    --cc=arnd@arndb.de \
    --cc=dedekind@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=v4l-dvb-maintainer@linuxtv.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.