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.
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
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
On Wed, May 28, 2003 at 12:04:17PM +0200, Marcin Dalecki wrote:
Harti Brandt wrote:
MDNO no and again no. This would repeat the same design mistake
MDthat is already in Linux. On API level you DO NOT WANT versioning.
MDWhat you really want is: type signature cheking. Like for example
MDdone
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
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
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
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
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
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
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
* 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
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
* 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
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
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.
On Wed, 28 May 2003, Marcin Dalecki wrote:
Harti Brandt wrote:
MDNO no and again no. This would repeat the same design mistake
MDthat is already in Linux. On API level you DO NOT WANT versioning.
MDWhat you really want is: type signature cheking. Like for example
MDdone through C++
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
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
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
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
On Wed, 28 May 2003, Marcin Dalecki wrote:
MDScott 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
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
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
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
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
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?*
: :
: :
Harti Brandt wrote:
MDNO no and again no. This would repeat the same design mistake
MDthat is already in Linux. On API level you DO NOT WANT versioning.
MDWhat you really want is: type signature cheking. Like for example
MDdone through C++ symbol mangling rules. If you can't do it like that
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
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
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
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
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.
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
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
.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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
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
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
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
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
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
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
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 :(
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
66 matches
Mail list logo
