Hi, Peter
> [Vladislav Malyshkin <[EMAIL PROTECTED]>]
> > Also, the function remove_duplicates can be written using make rules
> > and functions. Using functions "foreach" "if" from make and
> > comparison you can easily build a function remove_duplicates in make,
> > no shell involved.
>
> Coul
> of SCSI cards is not a good enough reason. People with multiple SCSI
> cards already change the order of scsi entries to get the probe order
> that suits them, LINK_FIRST will make that even easier.
Why not solve the generic problem. If you give a list of requirements to
tsort one per line it
[Vladislav Malyshkin <[EMAIL PROTECTED]>]
> Also, the function remove_duplicates can be written using make rules
> and functions. Using functions "foreach" "if" from make and
> comparison you can easily build a function remove_duplicates in make,
> no shell involved.
Could you please write me t
[hpa]
> I would tend to agree with Linus on that. If that's truly what
> you're doing, it would be rather nonobvious.
Well, ok, opinion vs. opinion. The thing is, userspace code almost
*never* needs to care about link order -- and, not counting boot loader
magic, kernel code didn't care about
Peter Samuelson wrote:
>
> To Keith, Michael and me, the cleanest way to remove duplicates is
> $(sort). Since some object files must *not* be sorted, we came up with
> a simple, readable way to declare that certain things had to come in a
> certain order -- the idea being that most of the time
[Peter Samuelson]
> > There are two ways to handle this:
> >
> > obj-$(CONFIG_WD80x3) += wd.o 8390.o
> > obj-$(CONFIG_EL2) += 3c503.o 8390.o
> > obj-$(CONFIG_NE2000) += ne.o 8390.o
> > obj-$(CONFIG_NE2_MCA) += ne2.o 8390.o
> > obj-$(CONFIG_HPLAN) += hp.o 8390.o
[John Alvord <[EMAIL P
[hpa]
> I was going to ask to what extent we genuinely need sorting, and if
> we might be better off trying to eliminate that need as much as
> possible.
We don't need sorting. We need removing of duplicates. The GNU make
sort function removes duplicates as a side effect, which is why we want
[Russell King]
> Since someone kindly enlightened me that LINK_FIRST was unsorted, I'm
> finding it very hard to grasp what the difference is between an
> unsorted LINK_FIRST and unsorted LINK_LAST list, and an unsorted
> obj-y list. From what I understand, obj-y = $(LINK_FIRST)
> $(LINK_LAST) ?
> > With CONFIG_USB=y and all other USB modules built as
> > modules (=m), linking usbdrv.o into the kernel image
> > gives this:
>
> > drivers/usb/usbdrv.o(.data+0x2f4): undefined reference to
>
> Works for me here, .config attached. Local changes, merge error, or
> similar? I don't have any
On Tue, 31 Oct 2000 09:31:09 -0800 (PST),
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>On Wed, 1 Nov 2000, Keith Owens wrote:
>>
>> LINK_FIRST is processed in the order it is specified, so a.o will be
>> linked before z.o when both are present. See the patch.
>
>So why don't you do the same thing
[Linus]
> But it doesn't even WORK.
>
> You need to have
>
> LINK_FIRST1
> LINK_FIRST2
> LINK_FIRST3
> ...
>
> etc to get the proper ordering.
??? No you don't. Perhaps you mean something else. Here's how
LINK_FIRST works:
Say you have foo.o, bar.o, baz.o and lots
On Tue, 31 Oct 2000 17:24:24 -0800,
"Dunlap, Randy" <[EMAIL PROTECTED]> wrote:
>Is it valid to run depmod like this before
>booting the kernel that has usbcore in-kernel?
>depmod -ae works after I boot that kernel + usbcore.
To run depmod against a new 2.4.0-test10 kernel,
make modules_install
> > > With CONFIG_USB=y and all other USB modules built as
> > > modules (=m), linking usbdrv.o into the kernel image
> > > gives this:
> >
> > > drivers/usb/usbdrv.o(.data+0x2f4): undefined reference to
> >
> > Works for me here, .config attached. Local changes, merge error, or
> > similar? I
Randy Dunlap wrote:
> With CONFIG_USB=y and all other USB modules built as
> modules (=m), linking usbdrv.o into the kernel image
> gives this:
> drivers/usb/usbdrv.o(.data+0x2f4): undefined reference to
Works for me here, .config attached. Local changes, merge error, or
similar? I don't have
Linus Torvalds wrote:
>
[snip]
>
> That was going to be my next question if somebody actually said "sure".
>
> The question was rhetorical, since the way LINK_FIRST is implemented
> means
> that it has all the same problems that $(obj-y) has, and is hard to get
> right in the generic case (but
On Tue, 31 Oct 2000 05:59:59 -0600, Peter Samuelson
<[EMAIL PROTECTED]> wrote:
>
>[Linus]
>> In short, we should _remove_ all traces of stuff like
>>
>> O_OBJS = $(filter-out $(export-objs), $(obj-y))
>>
>> It's wrong.
>>
>> We should just have
>>
>> O_OBJS = $(obj-y)
>>
>> which i
On Tue, 31 Oct 2000, Russell King wrote:
> Linus Torvalds writes:
> > On Wed, 1 Nov 2000, Keith Owens wrote:
> > > LINK_FIRST is processed in the order it is specified, so a.o will be
> > > linked before z.o when both are present. See the patch.
> >
> > So why don't you do the same thing for
Linus Torvalds writes:
> On Wed, 1 Nov 2000, Keith Owens wrote:
> > LINK_FIRST is processed in the order it is specified, so a.o will be
> > linked before z.o when both are present. See the patch.
>
> So why don't you do the same thing for obj-y, then?
>
> Why can't you do
>
> LINK_FIRST
"H. Peter Anvin" <[EMAIL PROTECTED]> said:
[...]
> Sounds like what you actually need is LINK_BEFORE() LINK_AFTER() and a
> topological sort.
Was suggested before, and shot down by Linus himself...
tsort(1) et al come handy.
--
Dr. Horst H. von Brand mailto:[EMAIL PROTE
Followup to: <[EMAIL PROTECTED]>
By author:Linus Torvalds <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Does anybody see any problems with it? Basically, we're sidestepping the
> sorting, because neither SCSI nor USB need it. Making the problem simpler
> is always good.
>
> Now, th
Ok, how about this approach? It only works for the case where we do not
have the kind of multiple stuff that drivers/net has, but hey, we don't
actually need to handle all the cases right now.
We can leave that for the future, as the configuration process is likely
to change anyway during 2.5.x
Also, the function remove_duplicates can be written using make rules and
functions.
Using functions "foreach" "if" from make and comparison you can easily
build
a function remove_duplicates in make, no shell involved.
so instead of $(sort) your will have $(remove_duplicates)
written entirely in ma
Followup to: <[EMAIL PROTECTED]>
By author:Linus Torvalds <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Tue, 31 Oct 2000, Peter Samuelson wrote:
> >
> > The thing that Keith's patch does is flush these things out into the
> > open. By using LINK_FIRST/LINK_LAST, we declare that
On Wed, 1 Nov 2000, Keith Owens wrote:
>
> LINK_FIRST is processed in the order it is specified, so a.o will be
> linked before z.o when both are present. See the patch.
So why don't you do the same thing for obj-y, then?
Why can't you do
LINK_FIRST=$(obj-y)
and be done with it?
On Tue, 31 Oct 2000, Peter Samuelson wrote:
>
> The thing that Keith's patch does is flush these things out into the
> open. By using LINK_FIRST/LINK_LAST, we declare that "these are the
> known issues" -- and then the rest of the objects are reordered, and if
> something breaks, we track it d
[Vladislav Malyshkin <[EMAIL PROTECTED]>]
> You can easily remove duplicates in object files without sorting.
> You can just use a shell written function.
This is true. That was something I forgot to mention. I have looked
at that as well, and it strikes me as even more of a hack than the
solu
Hi, Peter,
You can easily remove duplicates in object files without sorting. You
can just use a shell written function.
This is an example of such function (bash written).
It removes the duplicates from the argument and prints the result to
stdout.
No sorting used.
# This function removes duplica
[rmk]
> > Take the instance where we need to link a.o first, z.o second, f.o
> > third and p.o fourth. How does LINK_FIRST / LINK_LAST guarantee
> > this?
It does. Read the patch. LINK_FIRST *itself* is not sorted.
> > LINK_FIRST = a.o z.o
> > LINK_LAST = f.o p.o
> >
> > But then what guar
On Tue, 31 Oct 2000 09:37:09 + (GMT),
Russell King <[EMAIL PROTECTED]> wrote:
>Keith Owens writes:
>> kbuild 2.5 splits link order into three categories. Those that must
>> come first, in the order they are specified - LINK_FIRST. Those that
>> must come last, in the order they are specifie
[kaos]
> > It still does not document the only real link order constraint in
> > USB. The almost complete lack of documentation on which link
> > orders are required and which are historical is extremely annoying
> > and _must_ be fixed, instead we just propagate the problem.
[Linus]
> We can
[Linus]
> In short, we should _remove_ all traces of stuff like
>
> O_OBJS = $(filter-out $(export-objs), $(obj-y))
>
> It's wrong.
>
> We should just have
>
> O_OBJS = $(obj-y)
>
> which is always right.
This part I agree with..
> And it should make all this FIRST/LAST object
Keith Owens writes:
> kbuild 2.5 splits link order into three categories. Those that must
> come first, in the order they are specified - LINK_FIRST. Those that
> must come last, in the order they are specified - LINK_LAST.
Keith, this sounds like a K-ludge.
Take the instance where we need to
On Mon, Oct 30, 2000 at 03:34:44PM -0500, Alexander Viro wrote:
> Unfortunately, it doesn't fix the thing. ->sync_page() is called ...
> Minimal patch (against -pre7) follows. It still leaves sync_page() problem
> open - any suggestions on that one are very welcome. ...
I needed to patch your p
Linus Torvalds wrote:
>
>
> On Mon, 30 Oct 2000, Jeff Garzik wrote:
> >
> > Ya know, sorting those lists causes this problem, too... usb.o is
> > listed first in the various lists, as is usbcore.o. Is it possible to
> > avoid sorting? Doing so will fix this, and also any other link order
> >
On Tue, 31 Oct 2000, Rusty Russell wrote:
>
> Quiet suggestion:
If I understood the GNU make syntax correctly (which is possibly not the
case - GNU make is possibly the only example of "overkill" to rival GNU
emacs), this looks like a reasonable idea.
However, it also looks like much more of
In message <[EMAIL PROTECTED]> you write:
> On Mon, 30 Oct 2000 16:47:15 -0800 (PST),
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >Actually, I think I have an even simpler solution, which is to change the
> >newstyle rule to something very simple:
> >
> > # Translate to Rules.make lists.
>
On Tue, 31 Oct 2000, Keith Owens wrote:
>
> You will compile all export objects, whether they are configured or
> not. The "obvious" fix does not work.
>
> MIX_OBJS:= $(filter $(export-objs),$(obj-y) $(obj-m))
>
> export_objs contains usb.o, obj-y contains usb_core.o, it does n
On Tue, 31 Oct 2000, Christoph Hellwig wrote:
> > newstyle rule to something very simple:
> >
> > # Translate to Rules.make lists.
> >
> > O_OBJS := $(obj-y)
> > M_OBJS := $(obj-m)
>
> This will destroy one nice feature of list-style makefiles:
> when you have an
On Tue, 31 Oct 2000 12:49:12 +1100,
Keith Owens <[EMAIL PROTECTED]> wrote:
>You will compile all export objects, whether they are configured or
>not. The "obvious" fix does not work.
>
> MIX_OBJS:= $(filter $(export-objs),$(obj-y) $(obj-m))
>
>export_objs contains usb.o, obj-y cont
On Mon, 30 Oct 2000 16:47:15 -0800 (PST),
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>Actually, I think I have an even simpler solution, which is to change the
>newstyle rule to something very simple:
>
> # Translate to Rules.make lists.
>
> O_OBJS := $(obj-y)
> M_OBJS
On Mon, Oct 30, 2000 at 06:52:08PM -0600, Michael Elizabeth Chastain wrote:
> Let me see if I have all this straight:
>
> (1) Change Rules.make to use "new style" variables as its native form.
> (1A) Add a "Compat.make" for old style Makefiles, and
> (1B) Continue to convert all the remai
On Mon, Oct 30, 2000 at 04:47:15PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 31 Oct 2000, Christoph Hellwig wrote:
> >
> > Old-style Makefiles are playing dirty tricks with defining
> > L_TARGET and then using O_TARGET for linking some onjects into
> > an intermediate object.
>
> Actually, I t
Let me see if I have all this straight:
(1) Change Rules.make to use "new style" variables as its native form.
(1A) Add a "Compat.make" for old style Makefiles, and
(1B) Continue to convert all the remaining old style Makefiles.
(2) Go with the "export-objs" style of declaring source fil
On Tue, 31 Oct 2000, Christoph Hellwig wrote:
>
> Old-style Makefiles are playing dirty tricks with defining
> L_TARGET and then using O_TARGET for linking some onjects into
> an intermediate object.
Actually, I think I have an even simpler solution, which is to change the
newstyle rule to some
On Mon, 30 Oct 2000 15:47:59 -0800 (PST),
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>On Tue, 31 Oct 2000, Keith Owens wrote:
>We should have some REALLY simple and to-the-point rules. Namely:
>
> - object files get linked in the order specified
>
>No ifs, buts, "except when the user doesn't care"
On Mon, Oct 30, 2000 at 03:51:53PM -0800, Linus Torvalds wrote:
> I hate your patch.
>
> I'd rather see "Rules.make" just base itself entirely off the new-style
> Makefiles, and have it use "$(obj-y)" instead of O_OBJS etc.
>
> Then, _old_style Makefiles could be fixed up by doing a
>
> i
On Tue, 31 Oct 2000, Christoph Hellwig wrote:
>
> But when we are changing makefiles everywhere - why not do the proper think
> and let the new-style makefiles share their code?
>
> (I have a patch ready - it just needs some forward-porting and testing)
I hate your patch.
I'd rather see "Rul
On Tue, 31 Oct 2000, Keith Owens wrote:
>
> >It is NEVER acceptable to change the order of object files.
>
> It is NEVER acceptable to change the order of object files, but only
> for those files where the developer has explicitly said what the order
> must be. In the case of USB, the develop
On Mon, Oct 30, 2000 at 03:40:24PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 31 Oct 2000, Christoph Hellwig wrote:
> >
> > It is simple - but a change in _every_ makefile is required.
> > And it is not really needed for old-style makefiles.
>
> Actually, you don't have to change every makefil
On Tue, 31 Oct 2000, Christoph Hellwig wrote:
>
> It is simple - but a change in _every_ makefile is required.
> And it is not really needed for old-style makefiles.
Actually, you don't have to change every makefile, because you CAN do this
all with a simple backwards-compatibility layer, some
On Mon, 30 Oct 2000 15:15:57 -0800 (PST),
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>I'm saying that EVERYTHING should be order-critical.
We (almost) agree about that, we are arguing about implementation
details. The existing implementation relies on the order that objects
are declared. In alm
In article <[EMAIL PROTECTED]> you wrote:
> We should just link it in the order specified:
> ld -r usbdrv.o $(obj-y)
>
> [...]
>
> Then we change the meaning of OX_OBJS, and instead of saying
>
> ALL_O = $(OX_OBJS) $(O_OBJS)
>
> we just say
>
> ALL_O = $(O_OBJS)
>
> and the me
On Mon, 30 Oct 2000, Alexander Viro wrote:
>
> Fine with me. Just let's remember that it should be revisited in 2.5.
> What about filemap_swapout()? If you agree with checking ->mapping
> there... looks like we are done with that crap for the time being.
Yup, I agree. I already applied your pa
On Tue, 31 Oct 2000, Keith Owens wrote:
> >
> >What would be wrong with just splitting it the other way, ie make OX_OBJS
> >be the expanded (but not ordered) list?
> >
> >That should take care of it, no?
>
> usbcore.o is both multi part *and* order critical. This is a
> combination that the ex
On Mon, 30 Oct 2000, Linus Torvalds wrote:
> Ok, sync_page() looks like a broken design, but I suspect that for
> expediency the simplest fix is to just make the NFS sync_page() (re-)check
> for "mapping == NULL", and let it be at that. Avoid the NULL pointer
> dereference (very small window al
On Mon, 30 Oct 2000, Jeff Garzik wrote:
> >
> > What would be wrong with just splitting it the other way, ie make OX_OBJS
> > be the expanded (but not ordered) list?
> >
> > That should take care of it, no?
>
> As an aside: remember you mentioned we should try to go 100% OX_OBJS
> anyway, el
On Mon, 30 Oct 2000, Alexander Viro wrote:
>
> [ sync_page brokenness ]
>
> To elaborate: the thing is called if we get a contention on the page lock.
Ok, sync_page() looks like a broken design, but I suspect that for
expediency the simplest fix is to just make the NFS sync_page() (re-)check
f
On Mon, 30 Oct 2000 18:02:34 -0500,
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>As an aside: remember you mentioned we should try to go 100% OX_OBJS
>anyway, eliminating O_OBJS completely...
That is a global change for 2.5, it would massively break 2.4 kbuild.
-
To unsubscribe from this list: send
On Mon, 30 Oct 2000 14:51:25 -0800 (PST),
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>On Tue, 31 Oct 2000, Keith Owens wrote:
>>
>> obj-y is used together with export-objs to split objects into O_OBJS
>> (no export symbol) and OX_OBJS (export symbol). If usbcore.o (multi)
>> is not replaced by i
Linus Torvalds wrote:
>
> On Tue, 31 Oct 2000, Keith Owens wrote:
> >
> > obj-y is used together with export-objs to split objects into O_OBJS
> > (no export symbol) and OX_OBJS (export symbol). If usbcore.o (multi)
> > is not replaced by its components then usb.o (in export-objs) is not
> > add
On Tue, 31 Oct 2000, Keith Owens wrote:
>
> obj-y is used together with export-objs to split objects into O_OBJS
> (no export symbol) and OX_OBJS (export symbol). If usbcore.o (multi)
> is not replaced by its components then usb.o (in export-objs) is not
> added to OX_OBJS so usb.c gets compil
On Mon, 30 Oct 2000 14:24:13 -0800 (PST),
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>This is the right fix. We MUST NOT sort those things.
Correction. We can sort them if we know what the correct link order
should be. In far too many Makefiles, we have no idea if the existing
order is required
On Mon, 30 Oct 2000, Jeff Garzik wrote:
>
> Ya know, sorting those lists causes this problem, too... usb.o is
> listed first in the various lists, as is usbcore.o. Is it possible to
> avoid sorting? Doing so will fix this, and also any other link order
> breakage like this that exists, too.
On Mon, 30 Oct 2000, Alexander Viro wrote:
>
> > I didn't actually miss it, I just looked at the users and decided that it
> > looks like they should never have this issue. But I might have missed
> > something. As far as I can tell, "read_cache_page()" is only used for
> > meta-data like thing
Keith Owens wrote:
>
> On Mon, 30 Oct 2000 17:01:20 -0500,
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >Keith Owens wrote:
> >> USB still gets unresolved symbols when part is in kernel, part is in
> >> modules and modversions are set. Patch against 2.4.0-test10-pre7, only
> >> affects drivers/usb
On Mon, 30 Oct 2000, Alexander Viro wrote:
> The last one is in deactivate_page_nolock() - there we check the
> ->mapping without pagecache_lock and without page lock. Hell
> knows whether it's a bug or not. Rik?
Shouldn't be a problem, since we'll have the lock at a time
we actually /do/ someth
On Mon, 30 Oct 2000 17:01:20 -0500,
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote:
>> USB still gets unresolved symbols when part is in kernel, part is in
>> modules and modversions are set. Patch against 2.4.0-test10-pre7, only
>> affects drivers/usb/Makefile.
>
>Or instead of all t
Keith Owens wrote:
>
> On Mon, 30 Oct 2000 11:32:33 -0800 (PST),
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > - pre7:
> >- Randy Dunlap, USB: printer.c, usb-storage, usb identification and
> > memory leak fixes
>
> USB still gets unresolved symbols when part is in kernel, part is in
On Mon, 30 Oct 2000, Alexander Viro wrote:
>
>
> On Mon, 30 Oct 2000, Linus Torvalds wrote:
>
> > How about just changing ->sync_page() semantics to own the page lock? That
> > sound slike the right thing anyway, no?
>
> It would kill the ->sync_page(), but yes, _that_ might be the right th
On Mon, 30 Oct 2000 11:32:33 -0800 (PST),
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> - pre7:
>- Randy Dunlap, USB: printer.c, usb-storage, usb identification and
> memory leak fixes
USB still gets unresolved symbols when part is in kernel, part is in
modules and modversions are set. P
On Mon, 30 Oct 2000, Linus Torvalds wrote:
> How about just changing ->sync_page() semantics to own the page lock? That
> sound slike the right thing anyway, no?
It would kill the ->sync_page(), but yes, _that_ might be the right thing ;-)
> I didn't actually miss it, I just looked at the use
On Mon, 30 Oct 2000, Alexander Viro wrote:
>
> Unfortunately, it doesn't fix the thing. ->sync_page() is called when we
> do not own the page lock and nfs_sync_page() uses page->mapping. Yes, we
> check it before calling the bloody thing, but we don't own the lock.
Good catch.
> Problem only
On Mon, 30 Oct 2000, Linus Torvalds wrote:
>
> Ok, this one contains at least a preliminary fix for the problem with
> truncate together with a concurrent page access - the bug that causes
> oopses in block_read_full_page() and filemap_nopage().
>
> This is a fairly minimal fix, and I'll stil
73 matches
Mail list logo
