linux-kernel - Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 9 Jun 2011 14:47:17 -0500
From:	Timur Tabi <timur@...escale.com>
To:	Randy Dunlap <randy.dunlap@...cle.com>
CC:	<alan@...rguk.ukuu.org.uk>, <arnd@...db.de>,
	<kumar.gala@...escale.com>, <benh@...nel.crashing.org>,
	<greg@...ah.com>, <akpm@...nel.org>, <cmetcalf@...era.com>,
	<konrad.wilk@...cle.com>, <dsaxena@...aro.org>,
	<linuxppc-dev@...ts.ozlabs.org>, <linux-kernel@...r.kernel.org>,
	<linux-console@...r.kernel.org>,
	<virtualization@...ts.linux-foundation.org>
Subject: Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor
 management driver

Randy Dunlap wrote:
>> > +enum fsl_hv_ioctl_cmd {
>> > +	FSL_HV_IOCTL_PARTITION_RESTART = _IOWR(0, 1, struct fsl_hv_ioctl_restart),
>> > +	FSL_HV_IOCTL_PARTITION_GET_STATUS = _IOWR(0, 2, struct fsl_hv_ioctl_status),
>> > +	FSL_HV_IOCTL_PARTITION_START = _IOWR(0, 3, struct fsl_hv_ioctl_start),
>> > +	FSL_HV_IOCTL_PARTITION_STOP = _IOWR(0, 4, struct fsl_hv_ioctl_stop),
>> > +	FSL_HV_IOCTL_MEMCPY = _IOWR(0, 5, struct fsl_hv_ioctl_memcpy),
>> > +	FSL_HV_IOCTL_DOORBELL = _IOWR(0, 6, struct fsl_hv_ioctl_doorbell),
>> > +	FSL_HV_IOCTL_GETPROP = _IOWR(0, 7, struct fsl_hv_ioctl_prop),
>> > +	FSL_HV_IOCTL_SETPROP = _IOWR(0, 8, struct fsl_hv_ioctl_prop),
>> > +};

> Missing an entry in Documentation/ioctl/ioctl-number.txt for 0 (with conflict!).

If I change it from 0, I'm going to break binary compatibility with our apps.  I
agree that maybe I shouldn't have picked 0, but considering how many conflicts
there already are, I wonder what the point is.  Even if I pick a number that is
currently not listed in the chart, that doesn't mean that it's actually not
being used, or that it won't conflict in the future.

So is it okay to stick with 0, or do I need to pick a new number?

-- 
Timur Tabi
Linux kernel developer at Freescale

--
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/