Re: policy on GPL'd drivers?
On Wed, 28 May 2003, Marcin Dalecki wrote: > Harti Brandt wrote: > > > MD>NO no and again no. This would repeat the same design mistake > > MD>that is already in Linux. On API level you DO NOT WANT versioning. > > MD>What you really want is: type signature cheking. Like for example > > MD>done through C++ symbol mangling rules. If you can't do it like that > > MD>then better leave it off as it is. Versioning in itself > > > > Type signature checking doesn't help you if the semantics of an API change > > without type changes. APIs should be semantically and syntactically stable > > in -STABLE. In -CURRENT they are expected to change. Managing a 3rd party > > driver for current is a nightmare, but may no be necessary once we have a > > -STABLE based on FreeBSD5. > > Sure sure. Perhaps I wasn't clear enough. Versioning doesn't help you > *anything* at all, but it is introducing new problems instead. Tons of them in > fact, if one looks at the Linux pain in this area. I suggested type signature > cheking in C++ style just to show how fundamentally flawed the idea of > version cheking is, but I can perfectly life with the situation as it is. > Uhh... it is not true that versioning does not help anything at all. i'm not sure what type signatures would help you with - knowing that foo(int, void *) still has teh same siganture doesn't tell you anything about what must be passed in as values what assumptions about call order with bar(void *) exist or anything else. > Symbol versioning is good to implement "multi-flavoured" single binary > objects (glibc uses it this way) and *not* for interface cheking. > Again my main point is versioning on the symbol level simply makes no sense and > worsens the situation. It's the fundamentally wrong approach to the actual > problem. The fact that Linux does something like this is only showing that Alan > Cox and Keith Owens didn't get it either and one shouldn't repeat the mistake. > uhhh... symbol versioning != library versioning and really, in case of glibc is pretty useless, very few if any glibc 2.2 progarms woiuld actually run on a 2.1 system, making it all pretty pointless > No more no less. > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Thu, 29 May 2003 12:48, Steve Kargl wrote: > > You are describing how it happens now, not WHY it happens like that. > > The WHY is obvious. The modules >(1) get rebuilt with the kernel. >(2) get installed with the kernel. >(3) get moved to /boot/kernel.old when a new kernel is installed. >(4) *Ideally*, if an API changes, the modules will be updated >by the developer/committer who breaks the modules; otherwise, >a person experiencing the breakage can ask for the commit to >be backed out. (Note, the *ideally* acknowledges that 64-bit >platforms seem to suffer API breakage more than ia32). > > > I think the existing solution has problems, and would prefer some > > external hooks for 3rd party modules. > > If you mean "third party modules without available sources", then >(1) The module should work for whatever -RELEASE i for which it was > built. (2) If you upgrade the OS, the module may or may not work. >(a) If it works, well aren't you lucky. >(b) If it doesn't work, then >(i) Ask the vendor for an update. >(ii) Hack around the breakage. >(iii) Downgrade to the *PROPER* -RELEASE. No, I mean third party modules with available sources, but not necessarily up to scratch code wise, or license wise. I think if the code is committed there is a much greater onus to make sure it doesn't break, and it incrases the load on everyone testing things. My basic point is that people want to use 3rd party modules - they aren't committers so it's not like they can just wack some code into the repo. The alternative for them is manual patching or using the ports framework - this is OK but suffers integration problems. I just want some way of rebuilding my 3rd party modules with my kernel that doesn't involve me having to jump through hoops :( I don't see what the down side of rebuilding 3rd party modules with a buildkernel and friends is. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Thu, May 29, 2003 at 09:20:23AM +0930, Daniel O'Connor wrote: > On Wed, 28 May 2003 23:58, Steve Kargl wrote: > > > > Because there are other, more elegant ways of dealing with these > > > > things. I don't like /usr/local/src anything, which was the main > > > > complaint. > > > > > > If there are more elegant solutions I would like to know what they are. > > > > > > I agree it isn't a great solution, but I can't see what is better. > > > > For GPL modules, put them in src/sys/gnu. If you don't > > want bloat, then use cvsup and a refuse file to not > > retrieve the sys/gnu. See the discussion that occurred > > many years ago when maestro3 support was committed to > > the tree. > > > > For non-viral licensed code, put it in its proper > > place in the sys/ hierarchy. Then use a WANT_XXX=yes > > knob in the /etc/make.conf to cause XXX to be built. > > You are describing how it happens now, not WHY it happens like that. The WHY is obvious. The modules (1) get rebuilt with the kernel. (2) get installed with the kernel. (3) get moved to /boot/kernel.old when a new kernel is installed. (4) *Ideally*, if an API changes, the modules will be updated by the developer/committer who breaks the modules; otherwise, a person experiencing the breakage can ask for the commit to be backed out. (Note, the *ideally* acknowledges that 64-bit platforms seem to suffer API breakage more than ia32). > I think the existing solution has problems, and would prefer some external > hooks for 3rd party modules. If you mean "third party modules without available sources", then (1) The module should work for whatever -RELEASE i for which it was built. (2) If you upgrade the OS, the module may or may not work. (a) If it works, well aren't you lucky. (b) If it doesn't work, then (i) Ask the vendor for an update. (ii) Hack around the breakage. (iii) Downgrade to the *PROPER* -RELEASE. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
* "M. Warner Losh" <[EMAIL PROTECTED]> [ Date: 2003-05-28 ]
[ w.r.t. Re: policy on GPL'd drivers? ]
> In message: <[EMAIL PROTECTED]>
> Juli Mallett <[EMAIL PROTECTED]> writes:
> : Jumping in a bit late as I thought someone would point this out, but
> : I thought that 3rd-party modules would live in /boot/modules?
>
> third party binary only modules. If you have source, for some
> definition of having source, to rebuild from, then it makes the most
> sense to keep it directly with the kernel. I'd not bother with
> symlinks as that just makes things more complicated and I'm not sure
> what gain you get from it.
I'm just curious how the third-party modules are kept around properly
across installkernel/buildkernel. Did you get MAKEOBJDIR/MAKEOBJDIRPREFIX
stuff working in the kernel build dir with ports modules? I'm glad we
aren't doing the realpath(3) thing in Make anymore, if so, as I doubt
I'm the only one with one hell of a convoluted setup in that sort of
thing.
And thanks for clearing up that that was binary-only ones, that makes
a bit more sense I suppose, assuming we're handling the module installs
all properly.
Thanx,
juli.
--
juli mallett. email: [EMAIL PROTECTED]; efnet: juli;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
In message: <[EMAIL PROTECTED]> Juli Mallett <[EMAIL PROTECTED]> writes: : Jumping in a bit late as I thought someone would point this out, but : I thought that 3rd-party modules would live in /boot/modules? third party binary only modules. If you have source, for some definition of having source, to rebuild from, then it makes the most sense to keep it directly with the kernel. I'd not bother with symlinks as that just makes things more complicated and I'm not sure what gain you get from it. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
* Daniel O'Connor <[EMAIL PROTECTED]> [ Date: 2003-05-28 ] [ w.r.t. Re: policy on GPL'd drivers? ] > > : I guess the problem with mandating somewhere in $PREFIX is that the > > : loader can't load it, so that's no good. I guess the only choice left is > > : /boot/modules. > > > > /boot/kernel > > > > : Any comments? > > > > Well, the patch was mostly a strawman to promote discussions about the > > issues. > > Fair enough. > > I think the port should install the source for the module in $PREFIX somewhere > (well known) and the module should live in /boot/kernel. > > When things need rebuilding it uses the installed source to do so.. Jumping in a bit late as I thought someone would point this out, but I thought that 3rd-party modules would live in /boot/modules? Also, as for them being tied to kernel configs at minimum, definitely, and I'd say that maybe /boot/modules should have e.g. foobar-IDENT.ko and a symlink to it from /boot/kernel.IDENT/foobar.ko or something, where IDENT is the kernel IDENT, that way multiple copies of a given 3rd-party module could exist, and probably we'd want to do something similar to the .old shuffling we do with kernels, anyway. Just a thought. Just putting them *with* each kernel does seeem a lot more direct, for sure, but I'd feel less gross adding a new symlink than copying one from an existing directory, which could be crudded up with $DEITY knows what. Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Wed, 28 May 2003 23:58, Steve Kargl wrote: > > > Because there are other, more elegant ways of dealing with these > > > things. I don't like /usr/local/src anything, which was the main > > > complaint. > > > > If there are more elegant solutions I would like to know what they are. > > > > I agree it isn't a great solution, but I can't see what is better. > > For GPL modules, put them in src/sys/gnu. If you don't > want bloat, then use cvsup and a refuse file to not > retrieve the sys/gnu. See the discussion that occurred > many years ago when maestro3 support was committed to > the tree. > > For non-viral licensed code, put it in its proper > place in the sys/ hierarchy. Then use a WANT_XXX=yes > knob in the /etc/make.conf to cause XXX to be built. You are describing how it happens now, not WHY it happens like that. I think the existing solution has problems, and would prefer some external hooks for 3rd party modules. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Wed, 28 May 2003 18:44, M. Warner Losh wrote: > : 1) If the port is updated between builds you end up with two version of > : the port installed. > > True. That's a weakness in the ports system, which is why we have > portupgrade. However, I didn't want to require portupgrade for > something so 'simple'. To a degree, but IMHO it isn't correct - I don't want to update the version of the port I am using without good reason. ie it should just recompile the code for the port you've already installed which is usually sufficient to get things working again. > : 2) You can't control where the module gets put - arguably this isn't a > : calamity, but I think it makes more sense for the modules to end up in > : /boot/modules, or some analog to it that is in $PREFIX. > > It should go in /boot/kernel, and not into $PREFIX, but that's a > philisophical problem I have with ports. ALL modules should be in /, > imho, since you don't know if the module is required to mount /. Yes, I agree. > : I guess the problem with mandating somewhere in $PREFIX is that the > : loader can't load it, so that's no good. I guess the only choice left is > : /boot/modules. > > /boot/kernel > > : Any comments? > > Well, the patch was mostly a strawman to promote discussions about the > issues. Fair enough. I think the port should install the source for the module in $PREFIX somewhere (well known) and the module should live in /boot/kernel. When things need rebuilding it uses the installed source to do so.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Wed, 28 May 2003 18:41, M. Warner Losh wrote: > : > the machine that built it, and not potentially somewhere else? What > : > about sysinstall upgrades that don't require src? > : > : Well, I am not 100% sure how the module building process works, but some > : analog of how it happens for things in sys/modules would be nice.. > > That is what is happening for the ports (or was last time I looked). In general yes, the ports are written like that, but I think rebuilding it directly from installed sources makes more sense. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
The only true solution to this is to version the APIs in the kernel and use the module versioning hooks to not load modules if the version isn't the right one. Will this require *any* new infrastructure to implement properly? Or is it simply a matter of maintaining API metadata regarding versions. I think it'd just be a question of maintaining the metadata. There may be a little code missing but I don't think it would take a lot of work to complete the versioning mechanism. Creating all the metadata to actually define and version the APIs is another issue entirely though. Each module can maintain dependency data, stating which versions of other modules it can work with. The kernel would need to create virtual modules that held the faked module version for that API component. That wouldn't be very hard, just a linker set to record the API version in a module version structure. Ideally, whenever possible each API component should be grouped into a module anyway, but when that isn't possible just defining a faked module version should work. So the module dependency graph would have "nodes" that are either real or virtual modules. Virtual modules are provided by the kernel proper only which only uses them to satisfy a module dependency? Interesting [hope I got that correct :)] Sounds like a neat way to create a module framework, guide for 3rd party and commercial drivers to get support from FreeBSD itself. dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Wed, 2003-05-28 at 17:48, dave wrote: > > > > I don't think anyone is talking about symbol versioning. The issue is > > stamping the API at a particular point in time that shows it behaves in > > a specified guaranteed way. > > > > The module system has all the hooks to deal with versioning. What's > > missing is not the mechanism but the knowledge, i.e. we don't know that > > module X won't work with kernel Y becuase we don't know what APIs > > module > > X may invoke and whether kernel Y supports them. > > > > > > > The only true solution to this is to version the APIs in the kernel and > > use the module versioning hooks to not load modules if the version > > isn't > > the right one. > > Will this require *any* new infrastructure to implement properly? Or is > it simply a matter of maintaining API metadata regarding versions. I think it'd just be a question of maintaining the metadata. There may be a little code missing but I don't think it would take a lot of work to complete the versioning mechanism. Creating all the metadata to actually define and version the APIs is another issue entirely though. Each module can maintain dependency data, stating which versions of other modules it can work with. The kernel would need to create virtual modules that held the faked module version for that API component. That wouldn't be very hard, just a linker set to record the API version in a module version structure. Ideally, whenever possible each API component should be grouped into a module anyway, but when that isn't possible just defining a faked module version should work. The kernel wouldn't then load a module if the kernel didn't support the APIs that the module depended upon. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On 28 May, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > "Daniel O'Connor" <[EMAIL PROTECTED]> writes: > : 2) You can't control where the module gets put - arguably this isn't a > : calamity, but I think it makes more sense for the modules to end up in > : /boot/modules, or some analog to it that is in $PREFIX. > > It should go in /boot/kernel, and not into $PREFIX, but that's a > philisophical problem I have with ports. ALL modules should be in /, > imho, since you don't know if the module is required to mount /. Another really good reason is that this is more likely to do the correct thing if you do a major system upgrade, like jumping from 4.x to 5.x, which are very likely to require different versions of the module, and discover some sort of problem when you boot the new kernel to test it before proceeding to the installworld step. The right thing should happen when you fall back to /boot/kernel.old, or /boot/kernel.itusedtowork, etc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
I don't think anyone is talking about symbol versioning. The issue is stamping the API at a particular point in time that shows it behaves in a specified guaranteed way. The module system has all the hooks to deal with versioning. What's missing is not the mechanism but the knowledge, i.e. we don't know that module X won't work with kernel Y becuase we don't know what APIs module X may invoke and whether kernel Y supports them. The only true solution to this is to version the APIs in the kernel and use the module versioning hooks to not load modules if the version isn't the right one. Will this require *any* new infrastructure to implement properly? Or is it simply a matter of maintaining API metadata regarding versions. I should probably try to understand the existing stuff more before asking too many more questions. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Wed, May 28, 2003 at 12:04:17PM +0200, Marcin Dalecki wrote: > Harti Brandt wrote: > > >MD>NO no and again no. This would repeat the same design mistake > >MD>that is already in Linux. On API level you DO NOT WANT versioning. > >MD>What you really want is: type signature cheking. Like for example > >MD>done through C++ symbol mangling rules. If you can't do it like that > >MD>then better leave it off as it is. Versioning in itself > > > >Type signature checking doesn't help you if the semantics of an API change > >without type changes. APIs should be semantically and syntactically stable > >in -STABLE. In -CURRENT they are expected to change. Managing a 3rd party > >driver for current is a nightmare, but may no be necessary once we have a > >-STABLE based on FreeBSD5. > > Sure sure. Perhaps I wasn't clear enough. Versioning doesn't help you > *anything* at all, but it is introducing new problems instead. Tons of them > in > fact, if one looks at the Linux pain in this area. I suggested type > signature > cheking in C++ style just to show how fundamentally flawed the idea of > version cheking is, but I can perfectly life with the situation as it is. > > Symbol versioning is good to implement "multi-flavoured" single binary I don't think anyone is talking about symbol versioning. The issue is stamping the API at a particular point in time that shows it behaves in a specified guaranteed way. The module system has all the hooks to deal with versioning. What's missing is not the mechanism but the knowledge, i.e. we don't know that module X won't work with kernel Y becuase we don't know what APIs module X may invoke and whether kernel Y supports them. Some of the suggestions, such as using an MD5 hash, will prevent panics by refusing to load kernels that haven't been rebuilt since the kernel was, but it's a bit of a sledgehammer, since you don't want to have to rebuild all your modules every time you rebuild the kernel and in some cases (third party modules) you won't be able to, so such a mechanism won't work in practice. The only true solution to this is to version the APIs in the kernel and use the module versioning hooks to not load modules if the version isn't the right one. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
Steve Kargl wrote: On Wed, May 28, 2003 at 06:40:46PM +0930, Daniel O'Connor wrote: On Wed, 28 May 2003 18:39, M. Warner Losh wrote: : > : Maybe the kernel build stuff can look in /usr/local/src/sys/modules : > : for things to build or something.. : > : > YUCK! : : *WHY?* : : I have asked this before BTW, and I haven't been told why it sucks. Because there are other, more elegant ways of dealing with these things. I don't like /usr/local/src anything, which was the main complaint. If there are more elegant solutions I would like to know what they are. I agree it isn't a great solution, but I can't see what is better. For GPL modules, put them in src/sys/gnu. If you don't want bloat, then use cvsup and a refuse file to not retrieve the sys/gnu. See the discussion that occurred many years ago when maestro3 support was committed to the tree. For non-viral licensed code, put it in its proper place in the sys/ hierarchy. Then use a WANT_XXX=yes knob in the /etc/make.conf to cause XXX to be built. It should be noted that the maestro3 case only involved the firmware being GPL, not the whole driver (I and the other author had explicit permission to license the kernel portion as BSDL). I still wonder about the validity of GPLing hexidecimal digits that represent binary machine code. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Wed, May 28, 2003 at 06:40:46PM +0930, Daniel O'Connor wrote: > On Wed, 28 May 2003 18:39, M. Warner Losh wrote: > > : > : Maybe the kernel build stuff can look in /usr/local/src/sys/modules > > : > : for things to build or something.. > > : > > > : > YUCK! > > : > > : *WHY?* > > : > > : I have asked this before BTW, and I haven't been told why it sucks. > > > > Because there are other, more elegant ways of dealing with these > > things. I don't like /usr/local/src anything, which was the main > > complaint. > > If there are more elegant solutions I would like to know what they are. > > I agree it isn't a great solution, but I can't see what is better. > For GPL modules, put them in src/sys/gnu. If you don't want bloat, then use cvsup and a refuse file to not retrieve the sys/gnu. See the discussion that occurred many years ago when maestro3 support was committed to the tree. For non-viral licensed code, put it in its proper place in the sys/ hierarchy. Then use a WANT_XXX=yes knob in the /etc/make.conf to cause XXX to be built. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
David Leimbach wrote: I have the GPLd source to the nforce drivers for Linux to support the nVidia nforce and nforce2 drivers in the kernel. To port these to FreeBSD would be an interesting task [if it hasn't already been done] and I have been looking for an excuse to get down and dirty with FBSD. [Yes... talk is cheap... just do it... Nike-a-go-go etc etc... :)] What is the policy on drivers that are clearly going to have to be GPLd by the viral clause since I am referencing a GPL driver to do the porting work myself? Are these allowed in the kernel? Well, you can't have a GPL driver in the kernel. But, alas, what "in the kernel" means is a bit fuzzy. Basically, no GPL code will go in GENERIC, because GENERIC is what we distribute, and having any GPL code in it would automatically taint the rest of the kernel. Also, there's some dispute on whether something that is linkable to the kernel, like a kernel module, would taint the kernel too. LGPL is preferred because there's no such doubts in this case. But I think the general consensus is that a kernel module can't taint the kernel. This would cause trouble mostly for installation. A user, of course, is free to compile a kernel with all the GPL code he wants. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] The one you want is never the one on sale. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Tue, 27 May 2003, Scott Long wrote: > Q wrote: > > I have been burnt by this in the past also. I think that it would be > > useful if you could allow kernel modules to be bound to a particular > > kernel "version/date/whatever", and have external modules refuse to load > > and/or complain if the kernel is upgraded. This should prevent > > unnecessary kernel panics when you upgrade. The Linux kernel has been > > doing this for years. > > > > Seeya...Q > > > > For the love of god, no! This creates a support nightmare. What > happens when a user installs his system and recompiles the kernel > without changing the source at all? His modules won't work, but > there is no reason why they shouldn't. What if one of those now > non-working modules is a driver for his hard drive? if you didn't change the code, no change to version => modules continue to work? > > Scott > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Wednesday, May 28, 2003, at 01:23 AM, Terry Lambert wrote: Q wrote: I have been burnt by this in the past also. I think that it would be useful if you could allow kernel modules to be bound to a particular kernel "version/date/whatever", and have external modules refuse to load and/or complain if the kernel is upgraded. This should prevent unnecessary kernel panics when you upgrade. The Linux kernel has been doing this for years. The FreeBSD DDI/DKI is not well enough documented, let alone versioned, let alone stable enough over time for this to work. Consider how long a third party binary-only driver would keep working for someone following -current, and you will see the problem. I think for current all bets are off anyway. I think supporting a 3rd party driver should really only "have-to" support releases. Now I may have to re-evaluate that thought for a stable tree as there is a level of confidence there that everything else will probably still work... it could be tricky :) [just scrambling to put the worms back in the can] Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
Daniel O'Connor wrote: On Wed, 28 May 2003 18:39, M. Warner Losh wrote: : > : Maybe the kernel build stuff can look in /usr/local/src/sys/modules : > : for things to build or something.. : > : > YUCK! : : *WHY?* : : I have asked this before BTW, and I haven't been told why it sucks. Because there are other, more elegant ways of dealing with these things. I don't like /usr/local/src anything, which was the main complaint. If there are more elegant solutions I would like to know what they are. Trivial: ./buildmykernel where buildmykernel contains something along the lines of: #!/bin/sh # My rebuild procedure ( cd /usr/src/; make buildkernel; make installkernel ) && \ ( cd /usr/ports/comms/ltxxx; make; make deinstall; make reinstall ) Don't forget the shell! Automatin is the easiest way to handle repeating tasks. As an added bonus it is documenting the decisions you have made. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
Harti Brandt wrote: MD>NO no and again no. This would repeat the same design mistake MD>that is already in Linux. On API level you DO NOT WANT versioning. MD>What you really want is: type signature cheking. Like for example MD>done through C++ symbol mangling rules. If you can't do it like that MD>then better leave it off as it is. Versioning in itself Type signature checking doesn't help you if the semantics of an API change without type changes. APIs should be semantically and syntactically stable in -STABLE. In -CURRENT they are expected to change. Managing a 3rd party driver for current is a nightmare, but may no be necessary once we have a -STABLE based on FreeBSD5. Sure sure. Perhaps I wasn't clear enough. Versioning doesn't help you *anything* at all, but it is introducing new problems instead. Tons of them in fact, if one looks at the Linux pain in this area. I suggested type signature cheking in C++ style just to show how fundamentally flawed the idea of version cheking is, but I can perfectly life with the situation as it is. Symbol versioning is good to implement "multi-flavoured" single binary objects (glibc uses it this way) and *not* for interface cheking. Again my main point is versioning on the symbol level simply makes no sense and worsens the situation. It's the fundamentally wrong approach to the actual problem. The fact that Linux does something like this is only showing that Alan Cox and Keith Owens didn't get it either and one shouldn't repeat the mistake. No more no less. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
In message: <[EMAIL PROTECTED]> "Daniel O'Connor" <[EMAIL PROTECTED]> writes: : On Wed, 28 May 2003 18:39, M. Warner Losh wrote: : > : > : Maybe the kernel build stuff can look in /usr/local/src/sys/modules : > : > : for things to build or something.. : > : > : > : > YUCK! : > : : > : *WHY?* : > : : > : I have asked this before BTW, and I haven't been told why it sucks. : > : > Because there are other, more elegant ways of dealing with these : > things. I don't like /usr/local/src anything, which was the main : > complaint. : : If there are more elegant solutions I would like to know what they are. : : I agree it isn't a great solution, but I can't see what is better. The patch I started on is one way. If all you want to do is build additional modules, something akin to MODULES_OVERRIDE that worked with absolute paths wouldn't be too horrible. I think it would just be a matter of setting MAKEOBJDIRPREIX a little better than we do now, but it is late, and my brain could be wrong. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
In message: <[EMAIL PROTECTED]> "Daniel O'Connor" <[EMAIL PROTECTED]> writes: : You need 'FORCE_PKG_REGISTER=' in the install target. True. : 1) If the port is updated between builds you end up with two version of the : port installed. True. That's a weakness in the ports system, which is why we have portupgrade. However, I didn't want to require portupgrade for something so 'simple'. : 2) You can't control where the module gets put - arguably this isn't a : calamity, but I think it makes more sense for the modules to end up in : /boot/modules, or some analog to it that is in $PREFIX. It should go in /boot/kernel, and not into $PREFIX, but that's a philisophical problem I have with ports. ALL modules should be in /, imho, since you don't know if the module is required to mount /. : I guess the problem with mandating somewhere in $PREFIX is that the loader : can't load it, so that's no good. I guess the only choice left is : /boot/modules. /boot/kernel : Any comments? Well, the patch was mostly a strawman to promote discussions about the issues. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
In message: <[EMAIL PROTECTED]> "Daniel O'Connor" <[EMAIL PROTECTED]> writes: : On Wed, 28 May 2003 15:29, Q wrote: : > By doing that aren't you assuming that the kernel will be installed on : > the machine that built it, and not potentially somewhere else? What : > about sysinstall upgrades that don't require src? : : Well, I am not 100% sure how the module building process works, but some : analog of how it happens for things in sys/modules would be nice.. That is what is happening for the ports (or was last time I looked). Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Wed, 28 May 2003 18:39, M. Warner Losh wrote: > : > : Maybe the kernel build stuff can look in /usr/local/src/sys/modules > : > : for things to build or something.. > : > > : > YUCK! > : > : *WHY?* > : > : I have asked this before BTW, and I haven't been told why it sucks. > > Because there are other, more elegant ways of dealing with these > things. I don't like /usr/local/src anything, which was the main > complaint. If there are more elegant solutions I would like to know what they are. I agree it isn't a great solution, but I can't see what is better. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
In message: <[EMAIL PROTECTED]> "Daniel O'Connor" <[EMAIL PROTECTED]> writes: : On Wed, 28 May 2003 14:41, M. Warner Losh wrote: : > In message: <[EMAIL PROTECTED]> : > : > "Daniel O'Connor" <[EMAIL PROTECTED]> writes: : > : Maybe the kernel build stuff can look in /usr/local/src/sys/modules for : > : things to build or something.. : > : > YUCK! : : *WHY?* : : I have asked this before BTW, and I haven't been told why it sucks. Because there are other, more elegant ways of dealing with these things. I don't like /usr/local/src anything, which was the main complaint. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Wed, 28 May 2003, Marcin Dalecki wrote: MD>Scott Long wrote: MD>> Q wrote: MD>> MD>>> Don't overreact. MD>> MD>> MD>> Heh. I live this hell every day with Linux in my day job. MD>> MD>>> I'm not suggesting taking the linux approach of MD>>> versioning every module. But rather allowing the loader or a module MD>>> (most likely a 3rd part or from a port) the ability to make a decision MD>>> based on some internal revision/date based "version" as to whether it is MD>>> safe to proceed to load. MD>> MD>> MD>> Ideally, every API would be versioned, and developers would be careful MD>> to architect their work so that the interfaces would be stable and MD>> gratuitous incompatibilities would be avoided. Alas, that is not always MD>> the case. MD>> MD>NO no and again no. This would repeat the same design mistake MD>that is already in Linux. On API level you DO NOT WANT versioning. MD>What you really want is: type signature cheking. Like for example MD>done through C++ symbol mangling rules. If you can't do it like that MD>then better leave it off as it is. Versioning in itself Type signature checking doesn't help you if the semantics of an API change without type changes. APIs should be semantically and syntactically stable in -STABLE. In -CURRENT they are expected to change. Managing a 3rd party driver for current is a nightmare, but may no be necessary once we have a -STABLE based on FreeBSD5. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
Scott Long wrote: Q wrote: Don't overreact. Heh. I live this hell every day with Linux in my day job. I'm not suggesting taking the linux approach of versioning every module. But rather allowing the loader or a module (most likely a 3rd part or from a port) the ability to make a decision based on some internal revision/date based "version" as to whether it is safe to proceed to load. Ideally, every API would be versioned, and developers would be careful to architect their work so that the interfaces would be stable and gratuitous incompatibilities would be avoided. Alas, that is not always the case. NO no and again no. This would repeat the same design mistake that is already in Linux. On API level you DO NOT WANT versioning. What you really want is: type signature cheking. Like for example done through C++ symbol mangling rules. If you can't do it like that then better leave it off as it is. Versioning in itself helps literally nothing and introduces many many problems in esp. if you are using a "vendor supplied" kernel and are trying to deploy add on modules - which is about the only point in time where you need to care about versioning. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
If we are talking about something like a network interface that needs to be preloaded, then I would be inclined to see a port install the module into /usr/local/modules (which is what 'rtc' uses) and have a pkg-install message that states the need to do a 'cp /usr/local/modules/if_??.ko /boot/kernel' and add 'if_??_load="YES"' to loader.conf so the network interface can be initialised on boot. This way the port isn't installing anything outside $PREFIX, and isn't directly altering /boot/loader.conf. Seeya...Q On Wed, 2003-05-28 at 15:54, Daniel O'Connor wrote: > On Wed, 28 May 2003 14:22, M. Warner Losh wrote: > > In message: <[EMAIL PROTECTED]> > > > > "Daniel O'Connor" <[EMAIL PROTECTED]> writes: > > : The only downside is that there are no hooks into the build process so > > : you have to be VERY careful when you update your kernel, or you get > > : panics :( > > > > This is true. I'd thought that MODULES_OVERRIDE would help, but ports > > builds and kernel builds are different enough to make this not easy to > > do. > > > > Wanna test a patch? Add a 'makeoptions PORTS_MODULES=comms/ltmdm' to > > your config file and apply the following patch. Lemme know how well > > (or poorly) it works. There's likely some hidden assumptions that > > make it appear to work for me. > > I don't see how it can work properly.. > > You need 'FORCE_PKG_REGISTER=' in the install target. > > I don't think how the patch is structured is sensible though :) > > 1) If the port is updated between builds you end up with two version of the > port installed. > > 2) You can't control where the module gets put - arguably this isn't a > calamity, but I think it makes more sense for the modules to end up in > /boot/modules, or some analog to it that is in $PREFIX. > > IMHO a standard should be set WRT item 2 so future ports writers know what the > proper way to do it is :) > > I guess the problem with mandating somewhere in $PREFIX is that the loader > can't load it, so that's no good. I guess the only choice left is > /boot/modules. > > Any comments? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
Q wrote: > I have been burnt by this in the past also. I think that it would be > useful if you could allow kernel modules to be bound to a particular > kernel "version/date/whatever", and have external modules refuse to load > and/or complain if the kernel is upgraded. This should prevent > unnecessary kernel panics when you upgrade. The Linux kernel has been > doing this for years. The FreeBSD DDI/DKI is not well enough documented, let alone versioned, let alone stable enough over time for this to work. Consider how long a third party binary-only driver would keep working for someone following -current, and you will see the problem. Basically, the only thing you are protecting against at that point is the driver not loading most of the time, and making people'se lives miserable bumping a single version number each time any non-static function in the kernel is changed. 8-(. FreeBSD would need to get a lot more serious about freezing kernel APIs for this type of thing to work. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Wed, 28 May 2003 15:29, Q wrote: > By doing that aren't you assuming that the kernel will be installed on > the machine that built it, and not potentially somewhere else? What > about sysinstall upgrades that don't require src? Well, I am not 100% sure how the module building process works, but some analog of how it happens for things in sys/modules would be nice.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
By doing that aren't you assuming that the kernel will be installed on the machine that built it, and not potentially somewhere else? What about sysinstall upgrades that don't require src? Seeya...Q On Wed, 2003-05-28 at 15:17, Daniel O'Connor wrote: > On Wed, 28 May 2003 14:41, M. Warner Losh wrote: > > In message: <[EMAIL PROTECTED]> > > > > "Daniel O'Connor" <[EMAIL PROTECTED]> writes: > > : Maybe the kernel build stuff can look in /usr/local/src/sys/modules for > > : things to build or something.. > > > > YUCK! > > *WHY?* > > I have asked this before BTW, and I haven't been told why it sucks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Wed, 28 May 2003 14:22, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > > "Daniel O'Connor" <[EMAIL PROTECTED]> writes: > : The only downside is that there are no hooks into the build process so > : you have to be VERY careful when you update your kernel, or you get > : panics :( > > This is true. I'd thought that MODULES_OVERRIDE would help, but ports > builds and kernel builds are different enough to make this not easy to > do. > > Wanna test a patch? Add a 'makeoptions PORTS_MODULES=comms/ltmdm' to > your config file and apply the following patch. Lemme know how well > (or poorly) it works. There's likely some hidden assumptions that > make it appear to work for me. I don't see how it can work properly.. You need 'FORCE_PKG_REGISTER=' in the install target. I don't think how the patch is structured is sensible though :) 1) If the port is updated between builds you end up with two version of the port installed. 2) You can't control where the module gets put - arguably this isn't a calamity, but I think it makes more sense for the modules to end up in /boot/modules, or some analog to it that is in $PREFIX. IMHO a standard should be set WRT item 2 so future ports writers know what the proper way to do it is :) I guess the problem with mandating somewhere in $PREFIX is that the loader can't load it, so that's no good. I guess the only choice left is /boot/modules. Any comments? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
David Leimbach wrote: > IANAL but I think the GPL has provisions for binaries that contain code that is > not necessarily dependant but merely aggregated into one package. Linking is not "mere agregation". If you can cite the section of the GPL you are talking about, it would be useful (this is a strawman: I have been dealing with lawyers over the GPL since 1992). > Still I agree... it must be a module for more than one very good reason :). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel module inconsistency was policy on GPL'd drivers?
Yes, I'm aware of the implications.. I was merely proposing a "ports legal" way of achieving the same result that Mike put forward without stuffing a foreign module into /boot. Although, like I said, this is not really a long term solution to the problem. All the port's originating kernel modules I am aware of use /usr/local/etc/rc.d scripts to load the module, and would therefore work with my suggested approach. If you manually loaded it using /boot/loader.conf you would need to put the module into /boot/kernel anyway, which would get moved out the next time you installed a new kernel. I guess the real question is which is more acceptable to the average user. Reinstalling a couple of ports each time you install a new kernel, or risking a kernel panic by not doing it? Obviously it would be better if you only needed to reinstall something only IF it was really required, but unless their is some alternative way of knowing this before loading the module it's hard to determine when that might be without causing a kernel panic. Seeya...Q On Wed, 2003-05-28 at 14:25, Scott Long wrote: > Q wrote: > > You could achieve the same result without breaking a bunch of cardinal > > rules by taking an MD5 hash of the kernel when the port is first > > installed, then modify the rc.d script that loads the module to only run > > if that MD5 hash matches the current kernel. If a mismatch occurs it > > should spew out an error saying the port should be reinstalled. > > > > This would most definitely work, although I'm not sure if this is the > > best way of resolving the issue in the longer term. > > > > Don't forget that some modules need to be loaded at boot time. Also, if > I recompile my kernel to trim down an unused driver, the MD5 will > change. > > Scott > > > Seeya...Q > > > > On Wed, 2003-05-28 at 14:04, Michael Edenfield wrote: > > > >>* Scott Long <[EMAIL PROTECTED]> [030527 23:51]: > >> > >> > I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not > uncommon that they require reinstalling after an upgrade. I have > experienced kernel panics on several occasions from out of date vmware > kernel modules. > >>> > >>>I'm really of the opinion that these ports should either live in the > >>>sys/ tree, or that magic should be devised to make sure that they are > >>>built along with the rest of the modules. > >> > >>Wouldn't it be sufficient to simply install the port modules into > >>/boot/kernel instead of /usr/local/wherever/it/goes/now? I > >>understand why most aren't put there now, due to the seperation of > >>base system from ports etc. But I would the benefits of violating > >>that principle outweigh the detriments: each time you reinstall your > >>kernel, /boot/kernel is moved out of the way... taking all the > >>outdated modules with it. Your port modules would fail to load, not > >>being in the right place, but that's far better than a panic. > >> > >>--Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Wed, 28 May 2003 14:41, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > > "Daniel O'Connor" <[EMAIL PROTECTED]> writes: > : Maybe the kernel build stuff can look in /usr/local/src/sys/modules for > : things to build or something.. > > YUCK! *WHY?* I have asked this before BTW, and I haven't been told why it sucks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel module inconsistency was policy on GPL'd drivers?
In message: <[EMAIL PROTECTED]>
Alexey Neyman <[EMAIL PROTECTED]> writes:
: I'd rather see something like
: PORTS_KMODS=audio/aureal-kmod xxx/yyy
: knob in the /etc/make.conf
Funny, I had similar thoughts before seeing your patch. Here's my
latest patch. You could put it in /etc/make.conf, but that's really
the wrong place because you typically would want to tie it to a
specific kernel config. However, there's nothing stopping you from
doing that if you want. I'd do it as a makeoptions, ala
MODULES_OVERRIDE.
This version fixes two bugs: make clean (reported by alex!), and
propigationg of SYSDIR. I suppose that I should replace /usr/ports
with something like PORTSDIR too, eh?
Warner
--- //depot/user/imp/freebsd-imp/sys/conf/kern.post.mk#10
+++ /paco/imp/p4/src/sys/conf/kern.post.mk
@@ -21,6 +21,19 @@
${target:S/^reinstall$/install/:S/^clobber$/cleandir/}
.endif
.endfor
+# Handle out of tree ports
+.if defined(PORTS_MODULES)
+.if defined(SYSDIR)
+PORTSMODULESENV=SYSDIR=${SYSDIR}
+.endif
+.for target in all install clean
+${target}: ports-${target}
+ports-${target}:
+.for __i in ${PORTS_MODULES}
+ cd /usr/ports/${__i}; ${PORTSMODULESENV} ${MAKE} ${target}
+.endfor
+.endfor
+.endif
.ORDER: kernel-install modules-install
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
In message: <[EMAIL PROTECTED]> "Daniel O'Connor" <[EMAIL PROTECTED]> writes: : Maybe the kernel build stuff can look in /usr/local/src/sys/modules for things : to build or something.. YUCK! Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
In message: <[EMAIL PROTECTED]>
"Daniel O'Connor" <[EMAIL PROTECTED]> writes:
: The only downside is that there are no hooks into the build process so you
: have to be VERY careful when you update your kernel, or you get panics :(
This is true. I'd thought that MODULES_OVERRIDE would help, but ports
builds and kernel builds are different enough to make this not easy to
do.
Wanna test a patch? Add a 'makeoptions PORTS_MODULES=comms/ltmdm' to
your config file and apply the following patch. Lemme know how well
(or poorly) it works. There's likely some hidden assumptions that
make it appear to work for me.
Warner
--- sys/conf/kern.post.mk#10Tue May 27 22:34:04 2003
+++ sys/conf/kern.post.mk Tue May 27 22:34:04 2003
@@ -41,6 +41,20 @@
.endif
.endif
+.if defined(PORTS_MODULES)
+modules: ports-all
+ports-all:
+.for __i in ${PORTS_MODULES}
+ cd /usr/ports/${__i}; ${MAKE} all
+.endfor
+
+modules-install: ports-install
+ports-install:
+.for __i in ${PORTS_MODULES}
+ cd /usr/ports/${__i}; ${MAKE} install
+.endfor
+.endif
+
.if !defined(DEBUG)
FULLKERNEL=${KERNEL_KO}
.else
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel module inconsistency was policy on GPL'd drivers?
Hi, there! On Wednesday 28 May 2003 08:25, Scott Long wrote: SL> Don't forget that some modules need to be loaded at boot time. Also, if SL> I recompile my kernel to trim down an unused driver, the MD5 will SL> change. It'll change even if you do not mess with the configuration at all: the uname information (the compile date) will change anyway. I'd rather see something like PORTS_KMODS=audio/aureal-kmod xxx/yyy knob in the /etc/make.conf Regards, Alexey. -- ,, | A quoi ca sert d'etre sur la terre | Alexey V. Neyman | Si c'est pour faire nos vies a genoux! | mailto:[EMAIL PROTECTED] `--( Les Rois du Monde )-' ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel module inconsistency was policy on GPL'd drivers?
Q wrote: You could achieve the same result without breaking a bunch of cardinal rules by taking an MD5 hash of the kernel when the port is first installed, then modify the rc.d script that loads the module to only run if that MD5 hash matches the current kernel. If a mismatch occurs it should spew out an error saying the port should be reinstalled. This would most definitely work, although I'm not sure if this is the best way of resolving the issue in the longer term. Don't forget that some modules need to be loaded at boot time. Also, if I recompile my kernel to trim down an unused driver, the MD5 will change. Scott Seeya...Q On Wed, 2003-05-28 at 14:04, Michael Edenfield wrote: * Scott Long <[EMAIL PROTECTED]> [030527 23:51]: I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not uncommon that they require reinstalling after an upgrade. I have experienced kernel panics on several occasions from out of date vmware kernel modules. I'm really of the opinion that these ports should either live in the sys/ tree, or that magic should be devised to make sure that they are built along with the rest of the modules. Wouldn't it be sufficient to simply install the port modules into /boot/kernel instead of /usr/local/wherever/it/goes/now? I understand why most aren't put there now, due to the seperation of base system from ports etc. But I would the benefits of violating that principle outweigh the detriments: each time you reinstall your kernel, /boot/kernel is moved out of the way... taking all the outdated modules with it. Your port modules would fail to load, not being in the right place, but that's far better than a panic. --Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Kernel module inconsistency was policy on GPL'd drivers?
You could achieve the same result without breaking a bunch of cardinal rules by taking an MD5 hash of the kernel when the port is first installed, then modify the rc.d script that loads the module to only run if that MD5 hash matches the current kernel. If a mismatch occurs it should spew out an error saying the port should be reinstalled. This would most definitely work, although I'm not sure if this is the best way of resolving the issue in the longer term. Seeya...Q On Wed, 2003-05-28 at 14:04, Michael Edenfield wrote: > * Scott Long <[EMAIL PROTECTED]> [030527 23:51]: > > > >I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not > > >uncommon that they require reinstalling after an upgrade. I have > > >experienced kernel panics on several occasions from out of date vmware > > >kernel modules. > > > > I'm really of the opinion that these ports should either live in the > > sys/ tree, or that magic should be devised to make sure that they are > > built along with the rest of the modules. > > Wouldn't it be sufficient to simply install the port modules into > /boot/kernel instead of /usr/local/wherever/it/goes/now? I > understand why most aren't put there now, due to the seperation of > base system from ports etc. But I would the benefits of violating > that principle outweigh the detriments: each time you reinstall your > kernel, /boot/kernel is moved out of the way... taking all the > outdated modules with it. Your port modules would fail to load, not > being in the right place, but that's far better than a panic. > > --Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Wed, 28 May 2003 13:17, Scott Long wrote: > > I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not > > uncommon that they require reinstalling after an upgrade. I have > > experienced kernel panics on several occasions from out of date vmware > > kernel modules. > > I'm really of the opinion that these ports should either live in the > sys/ tree, or that magic should be devised to make sure that they are > built along with the rest of the modules. Agreed :) I don't think it makes sense committing them into the sys tree, as it bloats everyones system and has potential licensing problems. Maybe the kernel build stuff can look in /usr/local/src/sys/modules for things to build or something.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
* Scott Long <[EMAIL PROTECTED]> [030527 23:51]: > >I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not > >uncommon that they require reinstalling after an upgrade. I have > >experienced kernel panics on several occasions from out of date vmware > >kernel modules. > > I'm really of the opinion that these ports should either live in the > sys/ tree, or that magic should be devised to make sure that they are > built along with the rest of the modules. Wouldn't it be sufficient to simply install the port modules into /boot/kernel instead of /usr/local/wherever/it/goes/now? I understand why most aren't put there now, due to the seperation of base system from ports etc. But I would the benefits of violating that principle outweigh the detriments: each time you reinstall your kernel, /boot/kernel is moved out of the way... taking all the outdated modules with it. Your port modules would fail to load, not being in the right place, but that's far better than a panic. --Mike pgp0.pgp Description: PGP signature
Re: policy on GPL'd drivers?
Q wrote: Don't overreact. Heh. I live this hell every day with Linux in my day job. I'm not suggesting taking the linux approach of versioning every module. But rather allowing the loader or a module (most likely a 3rd part or from a port) the ability to make a decision based on some internal revision/date based "version" as to whether it is safe to proceed to load. Ideally, every API would be versioned, and developers would be careful to architect their work so that the interfaces would be stable and gratuitous incompatibilities would be avoided. Alas, that is not always the case. I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not uncommon that they require reinstalling after an upgrade. I have experienced kernel panics on several occasions from out of date vmware kernel modules. I'm really of the opinion that these ports should either live in the sys/ tree, or that magic should be devised to make sure that they are built along with the rest of the modules. Scott Seeya...Q On Wed, 2003-05-28 at 13:13, Scott Long wrote: Q wrote: I have been burnt by this in the past also. I think that it would be useful if you could allow kernel modules to be bound to a particular kernel "version/date/whatever", and have external modules refuse to load and/or complain if the kernel is upgraded. This should prevent unnecessary kernel panics when you upgrade. The Linux kernel has been doing this for years. Seeya...Q For the love of god, no! This creates a support nightmare. What happens when a user installs his system and recompiles the kernel without changing the source at all? His modules won't work, but there is no reason why they shouldn't. What if one of those now non-working modules is a driver for his hard drive? Scott On Wed, 2003-05-28 at 12:17, Daniel O'Connor wrote: On Tue, 27 May 2003 22:13, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a "kernel module" is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure "patching" it won't be enough to map the linux innards to freebsd's. There are already a number of kernel modules in the ports tree (eg nvidia drivers, ltmdm modem driver, aureal sound driver, etc). The only downside is that there are no hooks into the build process so you have to be VERY careful when you update your kernel, or you get panics :( (I found this recently, some change broke all of my 3rd party modules and caused panics when I tried to load them). I would really like some way of getting external modules rebuilt at the same time as buildkernel and friends, otherwise you have to remember to rebuild the affected ports, and it is a pain in the ass. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
Don't overreact. I'm not suggesting taking the linux approach of versioning every module. But rather allowing the loader or a module (most likely a 3rd part or from a port) the ability to make a decision based on some internal revision/date based "version" as to whether it is safe to proceed to load. I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not uncommon that they require reinstalling after an upgrade. I have experienced kernel panics on several occasions from out of date vmware kernel modules. Seeya...Q On Wed, 2003-05-28 at 13:13, Scott Long wrote: > Q wrote: > > I have been burnt by this in the past also. I think that it would be > > useful if you could allow kernel modules to be bound to a particular > > kernel "version/date/whatever", and have external modules refuse to load > > and/or complain if the kernel is upgraded. This should prevent > > unnecessary kernel panics when you upgrade. The Linux kernel has been > > doing this for years. > > > > Seeya...Q > > > > For the love of god, no! This creates a support nightmare. What > happens when a user installs his system and recompiles the kernel > without changing the source at all? His modules won't work, but > there is no reason why they shouldn't. What if one of those now > non-working modules is a driver for his hard drive? > > Scott > > > > On Wed, 2003-05-28 at 12:17, Daniel O'Connor wrote: > > > >>On Tue, 27 May 2003 22:13, David Leimbach wrote: > >> > However the idea is that all GPL infected stuff be isolated, allowing a > fully working kernel without GPL stuff in there. > >>> > >>>Sounds like a "kernel module" is the way to go then. Perhaps it could > >>>exist in the ports tree instead of the mainline kernel sources :). I > >>>know > >>>I'd be happy with that... the problem is hosting the driver since I am > >>>sure > >>>"patching" it won't be enough to map the linux innards to freebsd's. > >> > >>There are already a number of kernel modules in the ports tree (eg nvidia > >>drivers, ltmdm modem driver, aureal sound driver, etc). > >> > >>The only downside is that there are no hooks into the build process so you > >>have to be VERY careful when you update your kernel, or you get panics :( > >> > >>(I found this recently, some change broke all of my 3rd party modules and > >>caused panics when I tried to load them). > >> > >>I would really like some way of getting external modules rebuilt at the same > >>time as buildkernel and friends, otherwise you have to remember to rebuild > >>the affected ports, and it is a pain in the ass. > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
Q wrote: I have been burnt by this in the past also. I think that it would be useful if you could allow kernel modules to be bound to a particular kernel "version/date/whatever", and have external modules refuse to load and/or complain if the kernel is upgraded. This should prevent unnecessary kernel panics when you upgrade. The Linux kernel has been doing this for years. Seeya...Q For the love of god, no! This creates a support nightmare. What happens when a user installs his system and recompiles the kernel without changing the source at all? His modules won't work, but there is no reason why they shouldn't. What if one of those now non-working modules is a driver for his hard drive? Scott On Wed, 2003-05-28 at 12:17, Daniel O'Connor wrote: On Tue, 27 May 2003 22:13, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a "kernel module" is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure "patching" it won't be enough to map the linux innards to freebsd's. There are already a number of kernel modules in the ports tree (eg nvidia drivers, ltmdm modem driver, aureal sound driver, etc). The only downside is that there are no hooks into the build process so you have to be VERY careful when you update your kernel, or you get panics :( (I found this recently, some change broke all of my 3rd party modules and caused panics when I tried to load them). I would really like some way of getting external modules rebuilt at the same time as buildkernel and friends, otherwise you have to remember to rebuild the affected ports, and it is a pain in the ass. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
I have been burnt by this in the past also. I think that it would be useful if you could allow kernel modules to be bound to a particular kernel "version/date/whatever", and have external modules refuse to load and/or complain if the kernel is upgraded. This should prevent unnecessary kernel panics when you upgrade. The Linux kernel has been doing this for years. Seeya...Q On Wed, 2003-05-28 at 12:17, Daniel O'Connor wrote: > On Tue, 27 May 2003 22:13, David Leimbach wrote: > > > However the idea is that all GPL infected stuff be isolated, allowing a > > > fully working kernel without GPL stuff in there. > > > > Sounds like a "kernel module" is the way to go then. Perhaps it could > > exist in the ports tree instead of the mainline kernel sources :). I > > know > > I'd be happy with that... the problem is hosting the driver since I am > > sure > > "patching" it won't be enough to map the linux innards to freebsd's. > > There are already a number of kernel modules in the ports tree (eg nvidia > drivers, ltmdm modem driver, aureal sound driver, etc). > > The only downside is that there are no hooks into the build process so you > have to be VERY careful when you update your kernel, or you get panics :( > > (I found this recently, some change broke all of my 3rd party modules and > caused panics when I tried to load them). > > I would really like some way of getting external modules rebuilt at the same > time as buildkernel and friends, otherwise you have to remember to rebuild > the affected ports, and it is a pain in the ass. -- Seeya...Q -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _ / Quinton Dolan - [EMAIL PROTECTED] __ __/ / / __/ / / /__ / _// / Gold Coast, QLD, Australia __/ __/ __/ / / - / Ph: +61 419 729 806 ___ / _\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Tue, 27 May 2003 22:13, David Leimbach wrote: > > However the idea is that all GPL infected stuff be isolated, allowing a > > fully working kernel without GPL stuff in there. > > Sounds like a "kernel module" is the way to go then. Perhaps it could > exist in the ports tree instead of the mainline kernel sources :). I > know > I'd be happy with that... the problem is hosting the driver since I am > sure > "patching" it won't be enough to map the linux innards to freebsd's. There are already a number of kernel modules in the ports tree (eg nvidia drivers, ltmdm modem driver, aureal sound driver, etc). The only downside is that there are no hooks into the build process so you have to be VERY careful when you update your kernel, or you get panics :( (I found this recently, some change broke all of my 3rd party modules and caused panics when I tried to load them). I would really like some way of getting external modules rebuilt at the same time as buildkernel and friends, otherwise you have to remember to rebuild the affected ports, and it is a pain in the ass. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
David Leimbach <[EMAIL PROTECTED]> writes: > Ugh... the network driver portion of the nforce drivers is *not* GPL'd but it > has a linux only and anti-reverse engineeing clause. ...which is null and void in countries with proper IP laws, such as Norway. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Tuesday 27 May 2003 08:43, David Leimbach wrote: > On Tuesday, May 27, 2003, at 07:36 AM, Wilko Bulte wrote: > > On Tue, May 27, 2003 at 02:35:41PM +0200, Stijn Hoop wrote: > >> On Tue, May 27, 2003 at 07:28:29AM -0500, David Leimbach wrote: > >>> I have the GPLd source to the nforce drivers for Linux > >>> to support the nVidia nforce and nforce2 drivers in the kernel. > >>> > >>> To port these to FreeBSD would be an interesting task [if it hasn't > >>> already been done] and I have been looking for an excuse to get > >>> down and dirty with FBSD. > >>> [Yes... talk is cheap... just do it... Nike-a-go-go etc etc... :)] > >>> > >>> What is the policy on drivers that are clearly going to have to be > >>> GPLd by the viral clause since I am referencing a GPL driver to do > >>> the > >>> porting work myself? Are these allowed in the kernel? > > > > Yes, see for example the GPL_ed floating point emulator. > > > > However the idea is that all GPL infected stuff be isolated, allowing a > > fully working kernel without GPL stuff in there. > > Sounds like a "kernel module" is the way to go then. Perhaps it > could exist in the ports tree instead of the mainline kernel sources > :). I know I'd be happy with that... the problem is hosting the > driver since I am sure "patching" it won't be enough to map the > linux innards to freebsd's. Get someone to pair with you and do a clean-room implementation. One of you studies the GPL'd driver and writes a specification. The other writes a BSD-licensed driver from the specification, BUT NEVER ONCE LOOKS AT THE GPL'D SOURCE. Virus removed. -- Chris BeHanna http://www.pennasoft.com Principal Consultant PennaSoft Corporation [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
David Leimbach wrote: On Tuesday, May 27, 2003, at 10:40AM, Alexander Kabaev <[EMAIL PROTECTED]> wrote: On Tue, 27 May 2003 10:32:42 -0500 David Leimbach <[EMAIL PROTECTED]> wrote: Ugh... the network driver portion of the nforce drivers is *not* GPL'd but it has a linux only and anti-reverse engineeing clause. Dave Then using the diver on FreeBSD will be a NVidia's license violation, wouldn't it? One more reason to keep it out of the tree. Just the network driver... the audio driver in the tarball is still GPL'd. Either which way I doubt either driver will go into the tree. I don't see any good reason to stick any of it in the kernel unless its absolutely necessary. I am not a religious person when it comes to licensing. I just don't like GPL style restrictions. Did you ever ask NVidia about they position on this? Perhaps they are more flexible then you may think and this whole discussion is simply pointless. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien <[EMAIL PROTECTED]> wrote: >On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: >> >However the idea is that all GPL infected stuff be isolated, allowing a >> >fully working kernel without GPL stuff in there. >> >> Sounds like a "kernel module" is the way to go then. Perhaps it could >> exist in the ports tree instead of the mainline kernel sources :). I >> know I'd be happy with that... the problem is hosting the driver since >> I am sure "patching" it won't be enough to map the linux innards to >> freebsd's. > >Depending on the functionality the driver provides, and the kernel API's >it uses; having it as a port may be impractical. The driver probably >needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would "have to" support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien <[EMAIL PROTECTED]> wrote: >On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: >> >However the idea is that all GPL infected stuff be isolated, allowing a >> >fully working kernel without GPL stuff in there. >> >> Sounds like a "kernel module" is the way to go then. Perhaps it could >> exist in the ports tree instead of the mainline kernel sources :). I >> know I'd be happy with that... the problem is hosting the driver since >> I am sure "patching" it won't be enough to map the linux innards to >> freebsd's. > >Depending on the functionality the driver provides, and the kernel API's >it uses; having it as a port may be impractical. The driver probably >needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would "have to" support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien <[EMAIL PROTECTED]> wrote: >On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: >> >However the idea is that all GPL infected stuff be isolated, allowing a >> >fully working kernel without GPL stuff in there. >> >> Sounds like a "kernel module" is the way to go then. Perhaps it could >> exist in the ports tree instead of the mainline kernel sources :). I >> know I'd be happy with that... the problem is hosting the driver since >> I am sure "patching" it won't be enough to map the linux innards to >> freebsd's. > >Depending on the functionality the driver provides, and the kernel API's >it uses; having it as a port may be impractical. The driver probably >needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would "have to" support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien <[EMAIL PROTECTED]> wrote: >On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: >> >However the idea is that all GPL infected stuff be isolated, allowing a >> >fully working kernel without GPL stuff in there. >> >> Sounds like a "kernel module" is the way to go then. Perhaps it could >> exist in the ports tree instead of the mainline kernel sources :). I >> know I'd be happy with that... the problem is hosting the driver since >> I am sure "patching" it won't be enough to map the linux innards to >> freebsd's. > >Depending on the functionality the driver provides, and the kernel API's >it uses; having it as a port may be impractical. The driver probably >needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would "have to" support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien <[EMAIL PROTECTED]> wrote: >On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: >> >However the idea is that all GPL infected stuff be isolated, allowing a >> >fully working kernel without GPL stuff in there. >> >> Sounds like a "kernel module" is the way to go then. Perhaps it could >> exist in the ports tree instead of the mainline kernel sources :). I >> know I'd be happy with that... the problem is hosting the driver since >> I am sure "patching" it won't be enough to map the linux innards to >> freebsd's. > >Depending on the functionality the driver provides, and the kernel API's >it uses; having it as a port may be impractical. The driver probably >needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would "have to" support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien <[EMAIL PROTECTED]> wrote: >On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: >> >However the idea is that all GPL infected stuff be isolated, allowing a >> >fully working kernel without GPL stuff in there. >> >> Sounds like a "kernel module" is the way to go then. Perhaps it could >> exist in the ports tree instead of the mainline kernel sources :). I >> know I'd be happy with that... the problem is hosting the driver since >> I am sure "patching" it won't be enough to map the linux innards to >> freebsd's. > >Depending on the functionality the driver provides, and the kernel API's >it uses; having it as a port may be impractical. The driver probably >needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would "have to" support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien <[EMAIL PROTECTED]> wrote: >On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: >> >However the idea is that all GPL infected stuff be isolated, allowing a >> >fully working kernel without GPL stuff in there. >> >> Sounds like a "kernel module" is the way to go then. Perhaps it could >> exist in the ports tree instead of the mainline kernel sources :). I >> know I'd be happy with that... the problem is hosting the driver since >> I am sure "patching" it won't be enough to map the linux innards to >> freebsd's. > >Depending on the functionality the driver provides, and the kernel API's >it uses; having it as a port may be impractical. The driver probably >needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would "have to" support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: > >However the idea is that all GPL infected stuff be isolated, allowing a > >fully working kernel without GPL stuff in there. > > Sounds like a "kernel module" is the way to go then. Perhaps it could > exist in the ports tree instead of the mainline kernel sources :). I > know I'd be happy with that... the problem is hosting the driver since > I am sure "patching" it won't be enough to map the linux innards to > freebsd's. Depending on the functionality the driver provides, and the kernel API's it uses; having it as a port may be impractical. The driver probably needs to change with the kernel and that is hard to handle as a port. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
>Remember that's it's legal to to distribute seperate binaries, >as long as you comply with the GPL for the GPL'ed binary, but >it's a violation of clause 6(b) of the GPL to combine them >into one binary and distribute them, if you are legally >obligated to not give out the source code for the non-GPL'ed >portion. And since the only thing that gives you the right >to use the code in the first place is the license... IANAL but I think the GPL has provisions for binaries that contain code that is not necessarily dependant but merely aggregated into one package. Still I agree... it must be a module for more than one very good reason :). > >-- Terry >___ >[EMAIL PROTECTED] mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
. > >Well, network driver is a special case as it is this weird binary >'kernel' + OS shim combination which is getting popular lately. Have you >thought about getting NVidia's permission to link non-GPLed shims with >their binary object? > I have thought about it... but don't know enough to pursue it at the moment. I am quite the amatuer... >A quick scan through NVidia audio driver sources suggests that the >device is very similar to Intel ICH2 AC'97-based cards. Should you see >is BSD-led ich.c driver can be reused instead of the Linux driver? >From the release notes: "the audio driver is based on the open source i810 audio driver but has been modified to work with NVIDIA hardware." I don't want to guess how much modification will be needed to make the nvidia one work. > >-- >Alexander Kabaev > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
Alexander Kabaev wrote: > Wilko Bulte <[EMAIL PROTECTED]> wrote: > > Yes, see for example the GPL_ed floating point emulator. Aside: I thought the license had been changed on this? > I and no doubt many others will insist on keeping GPLed drivers out of > the tree. I have no objections for this drivers to be confined in ports > though. So will anyone with lawyers who wants to distribute a precompiled kernel binary. Since the console will work without the driver statically compiled into the kernel, a kernel module is really the best course of action for something like this, so that a kernel with, for example, licensed proprietary ISDN drivers, or the proprietary licensed OSS sound drivers, can still use the driver without a license conflict. Remember that's it's legal to to distribute seperate binaries, as long as you comply with the GPL for the GPL'ed binary, but it's a violation of clause 6(b) of the GPL to combine them into one binary and distribute them, if you are legally obligated to not give out the source code for the non-GPL'ed portion. And since the only thing that gives you the right to use the code in the first place is the license... -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Tue, 27 May 2003 10:49:40 -0500 David Leimbach <[EMAIL PROTECTED]> wrote: > > On Tuesday, May 27, 2003, at 10:40AM, Alexander Kabaev <[EMAIL PROTECTED]> > wrote: > > >On Tue, 27 May 2003 10:32:42 -0500 > >David Leimbach <[EMAIL PROTECTED]> wrote: > > > >> Ugh... the network driver portion of the nforce drivers is *not* > >> GPL'd but it > >> has a linux only and anti-reverse engineeing clause. > >> > >> Dave > > > >Then using the diver on FreeBSD will be a NVidia's license violation, > >wouldn't it? One more reason to keep it out of the tree. > > Just the network driver... the audio driver in the tarball is still > GPL'd. Well, network driver is a special case as it is this weird binary 'kernel' + OS shim combination which is getting popular lately. Have you thought about getting NVidia's permission to link non-GPLed shims with their binary object? A quick scan through NVidia audio driver sources suggests that the device is very similar to Intel ICH2 AC'97-based cards. Should you see is BSD-led ich.c driver can be reused instead of the Linux driver? -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 10:40AM, Alexander Kabaev <[EMAIL PROTECTED]> wrote: >On Tue, 27 May 2003 10:32:42 -0500 >David Leimbach <[EMAIL PROTECTED]> wrote: > >> Ugh... the network driver portion of the nforce drivers is *not* >> GPL'd but it >> has a linux only and anti-reverse engineeing clause. >> >> Dave > >Then using the diver on FreeBSD will be a NVidia's license violation, >wouldn't it? One more reason to keep it out of the tree. Just the network driver... the audio driver in the tarball is still GPL'd. Either which way I doubt either driver will go into the tree. I don't see any good reason to stick any of it in the kernel unless its absolutely necessary. I am not a religious person when it comes to licensing. I just don't like GPL style restrictions. > >-- >Alexander Kabaev > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: policy on GPL'd drivers?
On Tue, May 27, 2003 at 10:23:04AM -0400, Alexander Kabaev wrote: > On Tue, 27 May 2003 07:20:17 -0700 > Steve Kargl <[EMAIL PROTECTED]> wrote: > > > On Tue, May 27, 2003 at 08:45:29AM -0400, Alexander Kabaev wrote: > > > On Tue, 27 May 2003 14:36:26 +0200 > > > > > > I and no doubt many others will insist on keeping GPLed drivers out > > > of the tree. I have no objections for this drivers to be confined in > > > ports though. > > > > kargl[205] ls /sys/gnu/dev/sound/pci > > csaimg.h* emu10k1-ac97.h emu10k1.h maestro3_dsp.h maestro3_reg.h > > > > The maestro3 driver is in the tree and is covered by the GPL > > for the same reasons that David will need to GPL the FreeBSD > > version of the nForce driver. > > > > -- > > Steve > This doesn't mean it is an open season for contaminating the tree with > GPL. Nobody said so. But this is a policy set by core.. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
