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.
On 9/16/06, Jim Gibbons <[email protected]> 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
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 <[email protected]> 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
[email protected]
Gibbons and Associates, Inc.
TEL: (408) 984-1441
900 Lafayette, Suite 704, Santa Clara, CA
FAX: (408) 247-6395
On 9/16/06, Jim Gibbons <[email protected]> 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 :)
On Fri, 15 Sep 2006 17:43:56 -0700
Jim Gibbons <[email protected]> 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 <[email protected]> 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
> [email protected]
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Sat, 2006-09-16 at 13:44 +0900, Stephen Hemminger wrote:
> On Fri, 15 Sep 2006 17:43:56 -0700
> Jim Gibbons <[email protected]> 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