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 th
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 insta
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
* "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
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 h
* 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
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 agr
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 s
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
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 version
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. Wha
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,
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
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 examp
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 be
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
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 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 t
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
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
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
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!
: > :
: > : *
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, w
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 upg
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
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/loca
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 load
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
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/kern
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
> unnece
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
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 wr
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
> : pan
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: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
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://
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
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
* 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 real
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 rev
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 loa
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 kern
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
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 mainl
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 PROTE
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
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 e
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 "k
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 "k
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 "k
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 "k
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 "k
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 "k
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 "k
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 instea
>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
.
>
>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 pursu
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 d
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 o
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
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 wi
61 matches
Mail list logo
