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
next prev parent 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.