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