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
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
