[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6D8AD8B@saturn3.aculab.com>
Date: Fri, 10 Jun 2011 09:32:08 +0100
From: "David Laight" <David.Laight@...LAB.COM>
To: "Arnd Bergmann" <arnd@...db.de>,
"Timur Tabi" <timur@...escale.com>, <linuxppc-dev@...ts.ozlabs.org>
Cc: <konrad.wilk@...cle.com>, <kumar.gala@...escale.com>,
<linux-kernel@...r.kernel.org>, <cmetcalf@...era.com>,
<akpm@...nel.org>, <linux-console@...r.kernel.org>,
<greg@...ah.com>, <virtualization@...ts.linux-foundation.org>,
<alan@...rguk.ukuu.org.uk>
Subject: RE: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisormanagement driver
> > +enum fsl_hv_ioctl_cmd {
> > + FSL_HV_IOCTL_PARTITION_RESTART = _IOWR(0, 1, struct
fsl_hv_ioctl_restart),
...
> > +};
>
> Using a #define here is usually preferred because then you
> can use #ifdef in a user application to check if a given
> value has been assigned.
It is also possible to add:
#define FSL_HV_IOCTL_PARTITION_RESTART FSL_HV_IOCTL_PARTITION_RESTART
to have much the same effect.
But there are many cases where #defines are better.
I only tend to use enums when the constanst are beting generated
by the expansion of a #define.
> More importantly, the code you have chose (0) conflicts with
> existing drivers (frame buffer, scsi and wavefront among others).
> Please chose a free one and
> add it to Documentation/ioctl/ioctl-number.txt in the same patch.
It is rather a PITA that, when 'int' went from 16 to 32 bits, the
BSD people used the high 16 bits for size/flags rather than
using the extra bits to help make ioctl's unique.
Linux seems to have copied BSD here - rather than SYSV.
One problem with clashing ioctl commands is when systems like
NetBSD are running linux binaries and need to translate ioctl
buffers to/from native format. If the ioctl commands are
unique this can be done much more easily.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists