> I think that Linux kernel code has to be GPL compatible but if it's not
> a derived work of Linux then it doesn't have to be GPL.
I agree. Not all the code in Linux is GPL anyhow, there's some BSD-licensed
code in there.
> I didn't derive the xenidc code from Linux and it's intended to be
> useful for use in other OSs too so there's a possibility it could be
> licensed differently. I'd have to get approval for my parts and the
> other copyright holders would have to agree.
If you haven't used GPL code that other people have copyright on, then it's
not a derived work in my IANAL opition. If you have, you just need their
consent. We did this for the frontend drivers, amongst other stuff, to make
it easier for BSD ports to pull in code.
Cheers,
Mark
> IANAL either.
>
> > > > > +#define traceonly( S ) S
> > > >
> > > > What is this for? lose the parens.
> > >
> > > For code which should only be compiled in when tracing is turned on.
> > > The parens are required, no?
> >
> > My mistake, I meant lose the spaces inside the parens.
>
> OK
>
> > > > > +#define XENIDC_CALLBACK_SERIALISER_INIT( name ) \
> > > > > +{ \
> > > > > + SPIN_LOCK_UNLOCKED, \
> > > > > + LIST_HEAD_INIT( name.list ), \
> > > > > + XENIDC_WORK_INIT \
> > > > > + ( name.work, xenidc_callback_serialiser_function, &name ), \
> > > > > + 0 \
> > > > > +}
> > > >
> > > > Does this really need a macro? I know a bunch of Linux code does it,
> > > > but it's always preferable if you can do it as an inline
> > > > function. Also, what does the SPIN_LOCK_UNLOCKED do there?
> > >
> > > This is for initialisation of statics.
> > >
> > > i.e.
> > >
> > > static xenidc_callback_serialiser fred =
> > > XENIDC_CALLBACK_SERIALISER_INIT( fred );
> > >
> > > Can't do this with an inline function.
> >
> > ok, in that case, it would've been clearer to use C99 structure
> > initializers, e.g.
> >
> > #define XENIDC_CALLBACK_SERIALISER_INIT(name) {
> > .foo = SPIN_LOCK_UNLOCKED,
> > ...
> > }
>
> OK
>
> > etc.
> >
> > > > More to come.
> >
> > FWIW, I plan to wait for an updated version that fixes the superficial
> > stuff and then get down to actually reviewing the xenidc code.
> >
> > Cheers,
> > Muli
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|