Re: Linus's poll variation

Re: Linus's poll variation

[Dan Kegel]

Lyle asked:
> Is someone working on Linus's poll variation discussed in this list a week ago? 

I think the interface still needs some discussion.
The interface Linus proposed is IMHO oriented towards ease of 
kernel implementation, and doesn't appear to be easy to use
for all applications.
cf. recent posts by John Gardiner Myers <jgmyers@netscape.com>
e.g. 
http://boudicca.tux.org/hypermail/linux-kernel/2000week44/0966.html
http://boudicca.tux.org/hypermail/linux-kernel/2000week45/0212.html
IMHO kqueue()/kevent() is closer to what the apps want.

Mike Jagdis, however, has done some work on speeding up the
existing poll() system call, and has an eye on implementing
the /dev/poll interface.  See
http://boudicca.tux.org/hypermail/linux-kernel/2000week45/0266.html
- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test10-pre7

[Vladislav Malyshkin]

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 make.
Vladislav

Peter Samuelson wrote:

> [Vladislav Malyshkin <mal@gromco.com>]
> > 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
> solutions I mentioned: it is yet another external shell process for
> each invocation of Rules.make (ie each directory).  As I said before,
> though, one man's hack is another man's clean design, so whatever.
>
> Your function is rather long; try this one instead (untested):
>
>   remove_duplicates () {
>     str='';
>     for i; do
>       case "$str " in *" $i "*) ;; *) str="$str $i" ;; esac
>     done
>     echo "$str"
>   }
>
> I still think anything outside the makefiles that's needed to organize
> the build process is a hack.  That includes scripts/pathdown.sh (yes, I
> do have a scheme to get rid of it) and 2.2.18 scripts/kwhich (yes, I
> did propose a working alternative).  It doesn't include scripts/mkdep.c
> (which must do a lot of work as efficiently as possible),
> scripts/Configure et al (which are really standalone programs), or
> scripts/split-include.c (which is really a continuation of Configure).
>
> Peter

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test10-pre7

[Linus Torvalds]

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, and the multiple object case may go away
entirely (ie the case of slhc and 8390 will become just a normal
configuration dependency: you'd have a "CONFIG_SLHC" entry that is
computed by the dependency graph at configuration time, rather than by the
Makefile at build time).

This is the simplest rule base that I could come up with that should work
for both SCSI and USB:

	# Translate to Rules.make lists.
	multi-used      := $(filter $(list-multi), $(obj-y) $(obj-m))
	multi-objs      := $(foreach m, $(multi-used), $($(basename $(m))-objs))
	active-objs     := $(sort $(multi-objs) $(obj-y) $(obj-m))

	O_OBJS          := $(obj-y)
	M_OBJS          := $(obj-m)
	MIX_OBJS        := $(filter $(export-objs), $(active-objs))

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, the above won't work for drivers/net, but I think it will work for
just about anything else. So let's just leave drivers/net alone for now.
Simplicity is good.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test10-pre7

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.10.10010311018180.7083-100000@penguin.transmeta.com>
By author:    Linus Torvalds <torvalds@transmeta.com>
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, the above won't work for drivers/net, but I think it will work for
> just about anything else. So let's just leave drivers/net alone for now.
> Simplicity is good.
> 

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.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test10-pre7

[Peter Samuelson]

[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
to use it.

As has been discussed, there are lots of ways to remove duplicates.
You can spawn a shell script, you can keep track of each "common" file
with a tristate make variable, you can play with deeply nested if
statements, and rumor has it you may be able to write a custom GNU make
function (though I have doubts, as I have tried this before and
couldn't get anything to work).

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 it would not be
needed.  Linus disagrees that our solution is simple, readable or
otherwise desirable.  That's basically the whole issue in a nutshell.

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test10-pre7

[H. Peter Anvin]

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 it would not be
> needed.  Linus disagrees that our solution is simple, readable or
> otherwise desirable.  That's basically the whole issue in a nutshell.
> 

I would tend to agree with Linus on that.  If that's truly what you're
doing, it would be rather nonobvious.

But the question, perhaps, is when does ordering matter.  I'm a little
concerned about things highly dependent on link ordering.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Linus's poll variation

[Lyle Coder]

Hello,
Is someone working on Linus's poll variation discussed in this list a week
ago?

Thanks
Lyle

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/