Messages in this thread | | | Date | Sat, 23 Jun 2007 10:49:05 +0100 | From | Alan Cox <> | Subject | Re: [patch 03/10] Allow userspace applications to use marker.h to parse the markers section in the kernel binary. |
| |
On Sat, 23 Jun 2007 10:32:09 +0100 Christoph Hellwig <hch@infradead.org> wrote:
> On Sat, Jun 23, 2007 at 10:25:15AM +0100, Alan Cox wrote: > > Getting the marker exports right is what is needed to avoid having an > > unreliable parser and ending up with a reliable one. > > > > Or would you rather someone loaded a JVM into kernel space so it was > > "shipped with the kernel" > > You're totall missing the point here. We're talking about kernel internal > interface, and the point for them has always been not to care about out > of tree users. There is no relation to anything involving a JVM here.
Of course there is Christoph.
If you have a system which generates and loads modules then they can't be in tree (as they don't exist except transiently). On the other hand if it outputs java byte codes then a JVM to process them can be in tree. It would be a stupid solution to the problem but you appear to be objecting to sane ones.
The system to create the dynamic modules could certainly be in-tree but to argue that code dynamically created should be "in tree" already is a bit silly really isn't it ?
A second way of point out your argument is totally and utterly bogus would be the MODULE_ interface. The modutils are clearly out of tree users.
So whats the difference between modutils and markers ? Would it suddenely change if modutils developed modinfo --dump-markers ?
Alan - 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/
| |