request for ioctl range for private devices

request for ioctl range for private devices

[Jim Gibbons]

I'm involved in the construction of a Linux based device that needs to 
use ioctl's to communicate between its kernel module and its daemons.  
The device is an embedded product.  We should never have any need to 
distribute this driver interface.

I would like to use an ioctl range that would be safe, now and in the 
future.  Given that we won't be putting this driver on any general 
computing platforms, it seems inappropriate to reserve an ioctl range 
for this device.

I would really like to use an ioctl range that is reserved for the class 
of private embedded devices.  That way, I could be sure that I would 
never conflict with any peripheral that we might use without a 
reservation specific to our device.

Would you consider reserving space for such ioctl's?

p.s. I am not a kernel developer and hence not a member of this mailing 
list.  Please cc me on any replies.

p.p.s. I first sent this request to Michael Chastain, who remains listed 
in Documentation/ioctl-number.txt.  He replied that he is no longer 
involved and referred me to this e-mail list.  Perhaps that document 
should be updated.

Re: request for ioctl range for private devices

[Miguel Ojeda]

On 9/16/06, Jim Gibbons <jim@gibbons.com> wrote:
>
> I would like to use an ioctl range that would be safe, now and in the
> future.  Given that we won't be putting this driver on any general
> computing platforms, it seems inappropriate to reserve an ioctl range
> for this device.
>

I'm trying to get a patch accepted, and I just modified the file to
appear in the ioctl-number list, so if they apply the patch, the magic
number will be automatically reserved.

I think it's the right approach. Anyway, you should write and send the
device driver first, for review, because some people disagree with
your ioctl use, and maybe they can ask you for use another way to
communicate special commands to your device.

If you are not going to submit the driver code ever, I think it will
be much more difficult to get a ioctl just for your private use. If
I'm right, you will have to keep your patch update on your own, as it
doesn't belong to linux at all.

      Miguel Ojeda

Re: request for ioctl range for private devices

[Jim Gibbons]

I can see that I wasn't as clear as I should have been.  Thank you for 
trying to figure it out anyway.

Please let me try again to explain.  We are using a driver interface to 
our kernel level code.  Our kernel level code is a loadable module.  We 
have no intention of modifying the kernel or of releasing our code.  We 
accept the implied maintenance responsibility on this private, embedded 
platform.

We will, however, use code from the public Linux sources.  We are 
planning to use 2.6 at the moment, but we hope to update in the future.  
We also expect that we will update our platform, possibly adding new, 
publicly supported devices to it.

In this environment, we want to allow our daemons to communicate with 
our kernel module via its driver interface.

With all this having been said, we would like to find a range of ioctls 
to use for this communication.  We don't want to reserve a range for 
ourselves.  That would be silly, since this is such a private 
situation.  We do think that such embedded use might be common, though, 
and we would like to see a range of ioctls reserved for private and 
experimental uses like ours.

I hope that such an ioctl range might be reserved, so that we can avoid 
conflict with other public devices in the future.

Thanks for your help.

Miguel Ojeda wrote:
> On 9/16/06, Jim Gibbons <jim@gibbons.com> wrote:
>>
>> I would like to use an ioctl range that would be safe, now and in the
>> future.  Given that we won't be putting this driver on any general
>> computing platforms, it seems inappropriate to reserve an ioctl range
>> for this device.
>>
>
> I'm trying to get a patch accepted, and I just modified the file to
> appear in the ioctl-number list, so if they apply the patch, the magic
> number will be automatically reserved.
>
> I think it's the right approach. Anyway, you should write and send the
> device driver first, for review, because some people disagree with
> your ioctl use, and maybe they can ask you for use another way to
> communicate special commands to your device.
>
> If you are not going to submit the driver code ever, I think it will
> be much more difficult to get a ioctl just for your private use. If
> I'm right, you will have to keep your patch update on your own, as it
> doesn't belong to linux at all.
>
>      Miguel Ojeda

-- 
Jim Gibbons
	jim@gibbons.com
Gibbons and Associates, Inc.
	TEL: (408) 984-1441
900 Lafayette, Suite 704, Santa Clara, CA
	FAX: (408) 247-6395

Re: request for ioctl range for private devices

[Miguel Ojeda]

On 9/16/06, Jim Gibbons <jim@gibbons.com> wrote:
>
> We do think that such embedded use might be common, though,
> and we would like to see a range of ioctls reserved for private and
> experimental uses like ours.
>

Sorry, I tought you were asking for a ioctl range just for you.

It seems fair to me to have a private ioctl range where anyone should
use anytime in the future, just for tests and private use. Althought,
I can't help you too much with that, you will have to wait to the true
maintainers, I was just trying to give you ideas comparing it to my
case and which approach I would take.

Just wait until someone more useful answer you :)

Re: request for ioctl range for private devices

[Stephen Hemminger]

On Fri, 15 Sep 2006 17:43:56 -0700
Jim Gibbons <jim@gibbons.com> wrote:

> I can see that I wasn't as clear as I should have been.  Thank you for 
> trying to figure it out anyway.
> 
> Please let me try again to explain.  We are using a driver interface to 
> our kernel level code.  Our kernel level code is a loadable module.  We 
> have no intention of modifying the kernel or of releasing our code.  We 
> accept the implied maintenance responsibility on this private, embedded 
> platform.

Then why should the main kernel developers do anything to help you
with your private effort?

> We will, however, use code from the public Linux sources.  We are 
> planning to use 2.6 at the moment, but we hope to update in the future.  
> We also expect that we will update our platform, possibly adding new, 
> publicly supported devices to it.


So it is by definition a derived work under GPL

> In this environment, we want to allow our daemons to communicate with 
> our kernel module via its driver interface.
> 
> With all this having been said, we would like to find a range of ioctls 
> to use for this communication.  We don't want to reserve a range for 
> ourselves.  That would be silly, since this is such a private 
> situation.  We do think that such embedded use might be common, though, 
> and we would like to see a range of ioctls reserved for private and 
> experimental uses like ours.
> 
> I hope that such an ioctl range might be reserved, so that we can avoid 
> conflict with other public devices in the future.
> 
> Thanks for your help.
> 
> Miguel Ojeda wrote:
> > On 9/16/06, Jim Gibbons <jim@gibbons.com> wrote:
> >>
> >> I would like to use an ioctl range that would be safe, now and in the
> >> future.  Given that we won't be putting this driver on any general
> >> computing platforms, it seems inappropriate to reserve an ioctl range
> >> for this device.
> >>
> >
> > I'm trying to get a patch accepted, and I just modified the file to
> > appear in the ioctl-number list, so if they apply the patch, the magic
> > number will be automatically reserved.
> >
> > I think it's the right approach. Anyway, you should write and send the
> > device driver first, for review, because some people disagree with
> > your ioctl use, and maybe they can ask you for use another way to
> > communicate special commands to your device.
> >
> > If you are not going to submit the driver code ever, I think it will
> > be much more difficult to get a ioctl just for your private use. If
> > I'm right, you will have to keep your patch update on your own, as it
> > doesn't belong to linux at all.
> >
> >      Miguel Ojeda
> 
> -- 
> Jim Gibbons
> 	jim@gibbons.com
> Gibbons and Associates, Inc.
> 	TEL: (408) 984-1441
> 900 Lafayette, Suite 704, Santa Clara, CA
> 	FAX: (408) 247-6395
> 
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: request for ioctl range for private devices

[Lee Revell]

On Sat, 2006-09-16 at 13:44 +0900, Stephen Hemminger wrote:
> On Fri, 15 Sep 2006 17:43:56 -0700
> Jim Gibbons <jim@gibbons.com> wrote:
> 
> > I can see that I wasn't as clear as I should have been.  Thank you for 
> > trying to figure it out anyway.
> > 
> > Please let me try again to explain.  We are using a driver interface to 
> > our kernel level code.  Our kernel level code is a loadable module.  We 
> > have no intention of modifying the kernel or of releasing our code.  We 
> > accept the implied maintenance responsibility on this private, embedded 
> > platform.
> 
> Then why should the main kernel developers do anything to help you
> with your private effort?

I think the request is valid, even for those planning to comply with the
GPL.  I'm working on an embedded device that has a similar requirement.
The code will not be submitted upstream, as the hardware is customized,
but of course we will provide driver sources to those who buy the
hardware as the GPL requires.  It would be useful to have a private
ioctl range for this.  And please don't tell me not to use an ioctl()
interface - it's the simplest way to communicate between kernel and
userspace, and since the code is not going upstream it's our choice.

Lee