[EMAIL PROTECTED] said:
> That is a lot of work for a very few special cases. OTOH, you could
> just add a few lines of __initcall code in two source files (which I
> did when I wrote inter_module_xxx) and swap the order of 3 lines in
> drivers/mtd/Makefile. Guess which alternative I am going
[EMAIL PROTECTED] said:
That is a lot of work for a very few special cases. OTOH, you could
just add a few lines of __initcall code in two source files (which I
did when I wrote inter_module_xxx) and swap the order of 3 lines in
drivers/mtd/Makefile. Guess which alternative I am going for?
On Sun, 14 Jan 2001 13:47:29 -0800 (PST),
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>On Sun, 14 Jan 2001, David Woodhouse wrote:
>> That's the one flaw in the inter_module_get() stuff - we could do with a
>> way to put entries in the table at _compile_ time, rather than _only_ at
>> run time.
>
On Sun, 14 Jan 2001, Linus Torvalds wrote:
> On Sun, 14 Jan 2001, David Woodhouse wrote:
> > That's the one flaw in the inter_module_get() stuff - we could do with a
> > way to put entries in the table at _compile_ time, rather than _only_
> > at run time.
> Ok, I can buy that. Not having to
On Sun, 14 Jan 2001, David Woodhouse wrote:
>
> That's the one flaw in the inter_module_get() stuff - we could do with a
> way to put entries in the table at _compile_ time, rather than _only_ at
> run time.
Ok, I can buy that. Not having to initialize explicitly would be nice, but
if so we
On Sun, 14 Jan 2001, Linus Torvalds wrote:
> This is what "request_module()" and "kmod" is all about. Once we probe the
> hardware, the drievr itself can ask for more drivers.
>
> I completely fail to see the arguments that have been brought up for drm
> doing ugly things. The code should
On Sun, 14 Jan 2001, David Woodhouse wrote:
>
> But in the case of the CFI probe code and also I believe DRM, we don't
> actually know precisely which feature we're going to require until we've
> done the hardware probe at runtime.
That's ok.
This is what "request_module()" and "kmod" is all
On Sun, 14 Jan 2001, Linus Torvalds wrote:
> Note that previously there _were_ order dependencies. In fact, I consider
> it very tasteless to have modules that act differently on whether another
> module is loaded. I saw some arguments saying that this is th "right
> thing", and I disagree
On Sun, 14 Jan 2001, David Woodhouse wrote:
>
> But I have no particular attachment to it. All I'm asking for is a way to
> avoid having init order dependencies where previously there was no need
> for them, by having a way to put entries in the inter_module_get() table
> at compile time.
On 13 Jan 2001, Linus Torvalds wrote:
> You miss _entirely_ the reason why "get_module_symbol()" was removed,
> and why I will not _ever_ accept it coming back.
>
> Hint #1: get_MODULE_symbol().
> Hint #2: compiled in functionality.
Er,... forgive me if I'm being overly dense here, but I can't
[EMAIL PROTECTED] (Keith Owens) wrote on 12.01.01 in <[EMAIL PROTECTED]>:
> On Fri, 12 Jan 2001 13:01:12 +0100,
> Daniel Phillips <[EMAIL PROTECTED]> wrote:
> >Keith Owens wrote:
> >> I want to completely remove this multi layered method for setting
> >> initialisation order and go back to
On Sun, 14 Jan 2001, Keith Owens wrote:
> Note I said allowed, not supported. I refuse to support any binary
> only modules, my standard response to problems logged against binary
> modules is "remove them and reproduce the problem". Checking for ABI
> violations is not supporting binary
On Sun, 14 Jan 2001 09:43:21 + (GMT),
David Woodhouse <[EMAIL PROTECTED]> wrote:
>On Sun, 14 Jan 2001, Keith Owens wrote:
>> That forces the maintenance load back onto the binary supplier and
>> removes the questions from l-k, including many of the oops reports with
>> binary only drivers in
On Sun, 14 Jan 2001, Keith Owens wrote:
> This is becoming more important as the kernel moves towards hot
> plugging devices, especially for binary only drivers. It is far better
> for the kernel community if modutils can say "cannot load module foo
> because its interfaces do not match the
On Sun, 14 Jan 2001, Keith Owens wrote:
This is becoming more important as the kernel moves towards hot
plugging devices, especially for binary only drivers. It is far better
for the kernel community if modutils can say "cannot load module foo
because its interfaces do not match the kernel,
On Sun, 14 Jan 2001 09:43:21 + (GMT),
David Woodhouse [EMAIL PROTECTED] wrote:
On Sun, 14 Jan 2001, Keith Owens wrote:
That forces the maintenance load back onto the binary supplier and
removes the questions from l-k, including many of the oops reports with
binary only drivers in the
[EMAIL PROTECTED] (Keith Owens) wrote on 12.01.01 in [EMAIL PROTECTED]:
On Fri, 12 Jan 2001 13:01:12 +0100,
Daniel Phillips [EMAIL PROTECTED] wrote:
Keith Owens wrote:
I want to completely remove this multi layered method for setting
initialisation order and go back to basics. I want
On 13 Jan 2001, Linus Torvalds wrote:
You miss _entirely_ the reason why "get_module_symbol()" was removed,
and why I will not _ever_ accept it coming back.
Hint #1: get_MODULE_symbol().
Hint #2: compiled in functionality.
Er,... forgive me if I'm being overly dense here, but I can't see
On Sun, 14 Jan 2001, David Woodhouse wrote:
But I have no particular attachment to it. All I'm asking for is a way to
avoid having init order dependencies where previously there was no need
for them, by having a way to put entries in the inter_module_get() table
at compile time.
Note
On Sun, 14 Jan 2001, Linus Torvalds wrote:
Note that previously there _were_ order dependencies. In fact, I consider
it very tasteless to have modules that act differently on whether another
module is loaded. I saw some arguments saying that this is th "right
thing", and I disagree
On Sun, 14 Jan 2001, David Woodhouse wrote:
But in the case of the CFI probe code and also I believe DRM, we don't
actually know precisely which feature we're going to require until we've
done the hardware probe at runtime.
That's ok.
This is what "request_module()" and "kmod" is all
On Sun, 14 Jan 2001, Linus Torvalds wrote:
This is what "request_module()" and "kmod" is all about. Once we probe the
hardware, the drievr itself can ask for more drivers.
I completely fail to see the arguments that have been brought up for drm
doing ugly things. The code should simply do
On Sun, 14 Jan 2001, David Woodhouse wrote:
That's the one flaw in the inter_module_get() stuff - we could do with a
way to put entries in the table at _compile_ time, rather than _only_ at
run time.
Ok, I can buy that. Not having to initialize explicitly would be nice, but
if so we
On Sun, 14 Jan 2001, Linus Torvalds wrote:
On Sun, 14 Jan 2001, David Woodhouse wrote:
That's the one flaw in the inter_module_get() stuff - we could do with a
way to put entries in the table at _compile_ time, rather than _only_
at run time.
Ok, I can buy that. Not having to
On Sun, 14 Jan 2001 13:47:29 -0800 (PST),
Linus Torvalds [EMAIL PROTECTED] wrote:
On Sun, 14 Jan 2001, David Woodhouse wrote:
That's the one flaw in the inter_module_get() stuff - we could do with a
way to put entries in the table at _compile_ time, rather than _only_ at
run time.
Ok, I can
In article <[EMAIL PROTECTED]>,
David Woodhouse <[EMAIL PROTECTED]> wrote:
>
>We don't need to overdesign it. get_module_symbol() basically provided
>this for us. The only thing really wrong with it was the lack of use
>count handling, which I fixed a while ago.
NO NO NO!
You miss _entirely_
On Sat, 13 Jan 2001 15:09:40 + (GMT),
David Woodhouse <[EMAIL PROTECTED]> wrote:
>Lack of [module symbol] runtime typechecking isn't a showstopper.
It is when users try to insert modules from kernel A into kernel B when
the ABI changed between A and B. This is not type checking to catch
David Woodhouse writes:
> We don't need to overdesign it. get_module_symbol() basically provided
> this for us. The only thing really wrong with it was the lack of use
> count handling, which I fixed a while ago.
And the fact that it doesn't work if you turn module support off, which
you'd want
On Sat, 13 Jan 2001, Keith Owens wrote:
> BTW, modutils cannot automatically fill in upward references when a
> module is loaded. A reference is a use count, an automatic reference
> would be an automatic use count with no way of removing it. Code that
> calls upwards to a symbol must perform
On Sat, 13 Jan 2001 12:46:00 +0100,
Christian Zander <[EMAIL PROTECTED]> wrote:
>I see what you mean. What do you suggest should be done in the context of
>the driver? As you can easily tell, I'm not overly familiar with the
>internal workings of the kernel. That and the mere impossibility to
On Sat, 13 Jan 2001 10:46:44 + (GMT),
David Woodhouse <[EMAIL PROTECTED]> wrote:
>On Sat, 13 Jan 2001, Keith Owens wrote:
>Actually, my testing showed that modutils was quite OK with symbols which
>may or may not be present. But compiling such code into the kernel, at
>least on MIPS and
On Sat, Jan 13, 2001 at 12:11:31PM +1100, [EMAIL PROTECTED] wrote:
> My apologies. I read the patch, not the full source code and the patch
> does not have enough programming context to show that the driver is
> only searching its own symbol space. In my own defense, the references
> to
On Sat, 13 Jan 2001, Keith Owens wrote:
> Over emphasis for humorous effect. Must remember to add smiley.
Heh. But it does deserve to get into the fortune file.
> What this patch and David Woodhouse's comments show is that I need to
> look at a generic and safe mechanism for kernel/module
On Sat, 13 Jan 2001, Keith Owens wrote:
Over emphasis for humorous effect. Must remember to add smiley.
Heh. But it does deserve to get into the fortune file.
What this patch and David Woodhouse's comments show is that I need to
look at a generic and safe mechanism for kernel/module symbol
On Sat, Jan 13, 2001 at 12:11:31PM +1100, [EMAIL PROTECTED] wrote:
My apologies. I read the patch, not the full source code and the patch
does not have enough programming context to show that the driver is
only searching its own symbol space. In my own defense, the references
to spinlock_t
On Sat, 13 Jan 2001 10:46:44 + (GMT),
David Woodhouse [EMAIL PROTECTED] wrote:
On Sat, 13 Jan 2001, Keith Owens wrote:
Actually, my testing showed that modutils was quite OK with symbols which
may or may not be present. But compiling such code into the kernel, at
least on MIPS and m68k,
On Sat, 13 Jan 2001 12:46:00 +0100,
Christian Zander [EMAIL PROTECTED] wrote:
I see what you mean. What do you suggest should be done in the context of
the driver? As you can easily tell, I'm not overly familiar with the
internal workings of the kernel. That and the mere impossibility to get
any
On Sat, 13 Jan 2001, Keith Owens wrote:
BTW, modutils cannot automatically fill in upward references when a
module is loaded. A reference is a use count, an automatic reference
would be an automatic use count with no way of removing it. Code that
calls upwards to a symbol must perform an
David Woodhouse writes:
We don't need to overdesign it. get_module_symbol() basically provided
this for us. The only thing really wrong with it was the lack of use
count handling, which I fixed a while ago.
And the fact that it doesn't work if you turn module support off, which
you'd want to
On Sat, 13 Jan 2001 15:09:40 + (GMT),
David Woodhouse [EMAIL PROTECTED] wrote:
Lack of [module symbol] runtime typechecking isn't a showstopper.
It is when users try to insert modules from kernel A into kernel B when
the ABI changed between A and B. This is not type checking to catch
In article [EMAIL PROTECTED],
David Woodhouse [EMAIL PROTECTED] wrote:
We don't need to overdesign it. get_module_symbol() basically provided
this for us. The only thing really wrong with it was the lack of use
count handling, which I fixed a while ago.
NO NO NO!
You miss _entirely_ the
On Fri, 12 Jan 2001 20:11:30 +0100,
Christian Zander <[EMAIL PROTECTED]> wrote:
>Saying that I should have made use of this mechanism for the specific
>code in the Nvidia driver that we are talking about clearly shows that
>you didn't look at it. The module used get_module_symbol to search its
> >> I ran into this while hacking the Nvidia kernel driver to work with
> >> 2.4.0. I got the driver working but it's not 100%
> >>
> >> Also where did get_module_symbol() and put_module_symbol() go?
> >
> >Patches for the NVIDIA binary X drivers following all these kernel
> >changes can be
[EMAIL PROTECTED] said:
> You just proved my point. It is extremely difficult to deduce the
> required initialisation order by reading an undocumented Makefile
> where the init order is implemented as a side effect of selection
> order. The existing method implies link order when none is
On Fri, 12 Jan 2001 13:01:12 +0100,
Daniel Phillips <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote:
>> I want to completely remove this multi layered method for setting
>> initialisation order and go back to basics. I want the programmer to
>> say "initialise E and F after G, H and I". The
Keith Owens wrote:
> I want to completely remove this multi layered method for setting
> initialisation order and go back to basics. I want the programmer to
> say "initialise E and F after G, H and I". The kernel build system
> works out the directed graph of initialisation order then controls
On Fri, 12 Jan 2001 10:27:34 + (GMT),
David Woodhouse <[EMAIL PROTECTED]> wrote:
>On Fri, 12 Jan 2001, Keith Owens wrote:
>> A typical graph would have scsi disk depends on scsi host adaptor group
>> which depends on pci.
>
>No. sd will happily take over any existing devices when as and when
On Fri, 12 Jan 2001, Keith Owens wrote:
> People need to realise that the problem is initialisation order,
> nothing more, nothing less. You have to determine and document the
> startup requirements for your code.
This is true. But I'd also agree with the implication which you probably
didn't
On Fri, 12 Jan 2001, Keith Owens wrote:
People need to realise that the problem is initialisation order,
nothing more, nothing less. You have to determine and document the
startup requirements for your code.
This is true. But I'd also agree with the implication which you probably
didn't
On Fri, 12 Jan 2001 10:27:34 + (GMT),
David Woodhouse [EMAIL PROTECTED] wrote:
On Fri, 12 Jan 2001, Keith Owens wrote:
A typical graph would have scsi disk depends on scsi host adaptor group
which depends on pci.
No. sd will happily take over any existing devices when as and when they
Keith Owens wrote:
I want to completely remove this multi layered method for setting
initialisation order and go back to basics. I want the programmer to
say "initialise E and F after G, H and I". The kernel build system
works out the directed graph of initialisation order then controls the
On Fri, 12 Jan 2001 13:01:12 +0100,
Daniel Phillips [EMAIL PROTECTED] wrote:
Keith Owens wrote:
I want to completely remove this multi layered method for setting
initialisation order and go back to basics. I want the programmer to
say "initialise E and F after G, H and I". The kernel build
[EMAIL PROTECTED] said:
You just proved my point. It is extremely difficult to deduce the
required initialisation order by reading an undocumented Makefile
where the init order is implemented as a side effect of selection
order. The existing method implies link order when none is
I ran into this while hacking the Nvidia kernel driver to work with
2.4.0. I got the driver working but it's not 100%
Also where did get_module_symbol() and put_module_symbol() go?
Patches for the NVIDIA binary X drivers following all these kernel
changes can be gotten from IRC
On Fri, 12 Jan 2001 20:11:30 +0100,
Christian Zander [EMAIL PROTECTED] wrote:
Saying that I should have made use of this mechanism for the specific
code in the Nvidia driver that we are talking about clearly shows that
you didn't look at it. The module used get_module_symbol to search its
own
On Fri, 12 Jan 2001 03:12:47 +0100,
Ingo Oeser <[EMAIL PROTECTED]> wrote:
>So why don't we use sth. like depmod for these issues and get the
>link order automagically (like we get module load order)?
depmod handles dependencies on symbols. Module Y needs a symbol from
module X so modprobe must
On Fri, Jan 12, 2001 at 12:14:44AM +1100, Keith Owens wrote:
> >What happens when we get a loop in init order because of binding and other init
> >order conflicts?
>
> The kernel does not support circular dependencies between providers and
> consumers. It does not matter whether they are built
[EMAIL PROTECTED] said:
> So you want two services, one static for code that does not do any
> initialisation and one dynamic for code that does do initialisation.
> Can you imagine the fun when somebody adds startup code to a routine
> that was using static registration?
Oh come on. If you
On Thu, 11 Jan 2001 13:09:13 + (GMT),
Alan Cox <[EMAIL PROTECTED]> wrote:
>> Stick to one method that works for all routines, dynamic registration.
>> If that imposes the occasional need for a couple of extra calls in some
>> routines and for people to think about initialisation order right
> Stick to one method that works for all routines, dynamic registration.
> If that imposes the occasional need for a couple of extra calls in some
> routines and for people to think about initialisation order right from
> the start then so be it, it is a small price to pay for long term
>
On Thu, 11 Jan 2001 12:32:10 +,
David Woodhouse <[EMAIL PROTECTED]> wrote:
>I'm not suggesting that we change it drastically, only that we add
>the option of static (compile-time) registration for those entries which
>require it.
So you want two services, one static for code that does
[EMAIL PROTECTED] said:
> Q. With your suggested static method, what happens when Y initialises
>before X, calls inter_module_get, retrieves X's static data and
>starts to use it before X has initialised?
> A. Oops!
No. You'd explicitly only use the static registration when object X
On Thu, 11 Jan 2001 11:42:24 +,
David Woodhouse <[EMAIL PROTECTED]> wrote:
>Taking away get_module_symbol() and providing a replacement which has link
>order problems wasn't really very sensible.
>
>It's too late to do the sensible thing and deprecate the old version rather
>than having a
[EMAIL PROTECTED] said:
> And what a pile of crud those patches are!! Instead of using the
> clean replacement interface for get_module_symbol, nvidia/
> patch-2.4.0-PR hard codes the old get_module_symbol algorithm as
> inline code.
Taking away get_module_symbol() and providing a replacement
[EMAIL PROTECTED] said:
And what a pile of crud those patches are!! Instead of using the
clean replacement interface for get_module_symbol, nvidia/
patch-2.4.0-PR hard codes the old get_module_symbol algorithm as
inline code.
Taking away get_module_symbol() and providing a replacement
On Thu, 11 Jan 2001 11:42:24 +,
David Woodhouse [EMAIL PROTECTED] wrote:
Taking away get_module_symbol() and providing a replacement which has link
order problems wasn't really very sensible.
It's too late to do the sensible thing and deprecate the old version rather
than having a 'flag
[EMAIL PROTECTED] said:
Q. With your suggested static method, what happens when Y initialises
before X, calls inter_module_get, retrieves X's static data and
starts to use it before X has initialised?
A. Oops!
No. You'd explicitly only use the static registration when object X
On Thu, 11 Jan 2001 12:32:10 +,
David Woodhouse [EMAIL PROTECTED] wrote:
I'm not suggesting that we change it drastically, only that we add
the option of static (compile-time) registration for those entries which
require it.
So you want two services, one static for code that does not do
Stick to one method that works for all routines, dynamic registration.
If that imposes the occasional need for a couple of extra calls in some
routines and for people to think about initialisation order right from
the start then so be it, it is a small price to pay for long term
stability
On Thu, 11 Jan 2001 13:09:13 + (GMT),
Alan Cox [EMAIL PROTECTED] wrote:
Stick to one method that works for all routines, dynamic registration.
If that imposes the occasional need for a couple of extra calls in some
routines and for people to think about initialisation order right from
[EMAIL PROTECTED] said:
So you want two services, one static for code that does not do any
initialisation and one dynamic for code that does do initialisation.
Can you imagine the fun when somebody adds startup code to a routine
that was using static registration?
Oh come on. If you
On Fri, Jan 12, 2001 at 12:14:44AM +1100, Keith Owens wrote:
What happens when we get a loop in init order because of binding and other init
order conflicts?
The kernel does not support circular dependencies between providers and
consumers. It does not matter whether they are built into
On Fri, 12 Jan 2001 03:12:47 +0100,
Ingo Oeser [EMAIL PROTECTED] wrote:
So why don't we use sth. like depmod for these issues and get the
link order automagically (like we get module load order)?
depmod handles dependencies on symbols. Module Y needs a symbol from
module X so modprobe must
On Thu, 11 Jan 2001 16:38:50 +1100,
Antony Suter <[EMAIL PROTECTED]> wrote:
>Allen Unueco wrote:
>> I ran into this while hacking the Nvidia kernel driver to work with
>> 2.4.0. I got the driver working but it's not 100%
>>
>> Also where did get_module_symbol() and put_module_symbol() go?
>
Allen Unueco wrote:
>
> Sometime around test10 or test11 unmap left vm_operations_struct. The
> comment implies its there but it's gone. Where did it go?
>
> How do I get a call back for a page unmap?
>
> I ran into this while hacking the Nvidia kernel driver to work with
> 2.4.0. I got the
Allen Unueco wrote:
Sometime around test10 or test11 unmap left vm_operations_struct. The
comment implies its there but it's gone. Where did it go?
How do I get a call back for a page unmap?
I ran into this while hacking the Nvidia kernel driver to work with
2.4.0. I got the driver
On Thu, 11 Jan 2001 16:38:50 +1100,
Antony Suter [EMAIL PROTECTED] wrote:
Allen Unueco wrote:
I ran into this while hacking the Nvidia kernel driver to work with
2.4.0. I got the driver working but it's not 100%
Also where did get_module_symbol() and put_module_symbol() go?
Patches for
On Tue, 09 Jan 2001 19:27:24 -0800,
Allen Unueco <[EMAIL PROTECTED]> wrote:
>Also where did get_module_symbol() and put_module_symbol() go?
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg08791.html
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg11497.html
-
To
On Tue, 09 Jan 2001 19:27:24 -0800,
Allen Unueco [EMAIL PROTECTED] wrote:
Also where did get_module_symbol() and put_module_symbol() go?
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg08791.html
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg11497.html
-
To
79 matches
Mail list logo
