Re: Son of crunch time: the list v1.2.

Re: Son of crunch time: the list v1.2.

[Nicholas Berry]

>>> Nicholas Wourms <nwourms@netscape.net> 10/22/02 01:32PM >>>
<snip>

> Can you mount LVM partitions with using EVMS tools?  We should probably 
> keep the two seperate if this is not the case.

Yes indeed you can. And much, much more.

Cheers,
Also Nicholas

> Cheers,
> Nicholas

Re: Son of crunch time: the list v1.2.

[Vamsi Krishna S .]

On Wed, Oct 23, 2002 at 11:03:20AM -0500, Rob Landley wrote:
> On Wednesday 23 October 2002 05:28, Vamsi Krishna S . wrote:
> 
> > We are not proposing the entire dprobes patch to be in kernel. It doesn't
> > have to be. We are proposing for inclusion the "kprobes" patchset at
> > http://www-124.ibm.com/linux/patches/?project_id=141 which provides
> > the basic infrastructure in the kernel for setting up and handling
> > breakpoints automatically in kernel space. Once this small piece is in,
> > we can implement comprehensive tools like dynamic probes as external
> > kernel modules without having to patch the kernel.
> 
> Okay, so if patch 1 is kprobes itself, what exactly is the status of patches 
> 2-4?  (Optional but nice?  Cleanups?  Or are you pushing as hard for them as 
> for part 1?)
> 
2-4 are additional features which are required to implement a tool like
dprobes. It is nice to have them all in the kernel, so full-featured tools
like dprobes could be built without touching the kernel.

> I thought 2-4 paved the way for dprobes, but if you're not trying to get 
> dprobes in...?
> 
dprobes doesn't have to be in the mainline kernel, but dprobes (or
any such tool) requires some basic support from the kernel for setting
up breakpoints. kprobes provides these fundamental facilities which
are useable as-is.

Thanks,
Vamsi.

-- 
Vamsi Krishna S.
Linux Technology Center,
IBM Software Lab, Bangalore.
Ph: +91 80 5044959
Internet: vamsi@in.ibm.com

Re: Son of crunch time: the list v1.2.

[Rob Landley]

On Wednesday 23 October 2002 05:28, Vamsi Krishna S . wrote:

> We are not proposing the entire dprobes patch to be in kernel. It doesn't
> have to be. We are proposing for inclusion the "kprobes" patchset at
> http://www-124.ibm.com/linux/patches/?project_id=141 which provides
> the basic infrastructure in the kernel for setting up and handling
> breakpoints automatically in kernel space. Once this small piece is in,
> we can implement comprehensive tools like dynamic probes as external
> kernel modules without having to patch the kernel.

Okay, so if patch 1 is kprobes itself, what exactly is the status of patches 
2-4?  (Optional but nice?  Cleanups?  Or are you pushing as hard for them as 
for part 1?)

I thought 2-4 paved the way for dprobes, but if you're not trying to get 
dprobes in...?

Rob

-- 
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad, 
CmdrTaco, liquid nitrogen ice cream, and caffienated jello.  Well why not?

Re: Son of crunch time: the list v1.2.

[Rob Landley]

On Tuesday 22 October 2002 12:32, Nicholas Wourms wrote:

> As was stated by Dave Jones[1], this is something that will probably should
> go in after the freeze.

This is just a thought, and it's from somebody who's not going to actually be 
making any of these decisions, but my idea of "goes in after the freeze" is 
the same as my idea of "goes in during the stable series".

If you'd be happy including something between stable.0 and stable.1, or 
stable.5 and stable.6, (whether "stable" is called "2.6", "3.0", or "fred") 
then it makes sense to put it in after the freeze.  But if you don't think it 
would be a good idea to insert it after stable.0, then inserting it after the 
freeze at all is a bit hypocritical.  (Otherwise the freeze isn't too 
meaningful.)

Now, given that, if it could go in during the stable series, why not wait 
until then and not confuse the issue during stabilization and shutdown of the 
-pre series?  (Or at least hold off until closer to dot-0 release date, and 
give the existing infrastructure a chance to settle down a bit first.  At the 
very least not rush to get too much in immediately after the freeze.)

Admittedly the first dozen releases of 2.4 are a bad example of "stable", but 
reiserfs did go in circa 2.4.1 and nobody really minded that bit.  Maybe LVM 
and EVMS are similar, self contained, can't possibly hurt anybody who isn't 
using it type things.  (I don't know.  The word "maybe" is an important 
weasel word in that sentence.)

Rob

-- 
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad, 
CmdrTaco, liquid nitrogen ice cream, and caffienated jello.  Well why not?

Re: Son of crunch time: the list v1.2.

[Vamsi Krishna S .]

On Tue, Oct 22, 2002 at 02:06:29AM +0000, Jeff Garzik wrote:
> 
> > 7) Dynamic Probes (dprobes team)
> > http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes
> 
> why does this need to be the mainline kernel?  this is another type of 
> thing that can live as a patch, IMO...
> 
We are not proposing the entire dprobes patch to be in kernel. It doesn't
have to be. We are proposing for inclusion the "kprobes" patchset at
http://www-124.ibm.com/linux/patches/?project_id=141 which provides
the basic infrastructure in the kernel for setting up and handling
breakpoints automatically in kernel space. Once this small piece is in,
we can implement comprehensive tools like dynamic probes as external
kernel modules without having to patch the kernel. 

-- 
Vamsi Krishna S.
Linux Technology Center,
IBM Software Lab, Bangalore.
Ph: +91 80 5044959
Internet: vamsi@in.ibm.com

Re: Son of crunch time: the list v1.2.

[george anzinger]

mbs wrote:
> 
> On Tuesday 22 October 2002 02:45, george anzinger wrote:
> > > > > 9) High resolution timers (George Anzinger, etc.)
> > > > > http://high-res-timers.sourceforge.net/
> > > >
> > > > no comment, I've heard arguments that high-res timers would be useful,
> > > > but haven't read the patch myself so won't comment...
> > >
> > > I vaguely remember Linus had some objections that it plays with the clock
> > > tick and potentially penalizes everybody...  Hmmm...
> > >
> > > A quick google comes up with this:
> > >
> > > http://www.cs.helsinki.fi/linux/linux-kernel/2002-28/0360.html
> >
> > Hm, I had not seen this.  He is right, but the patch
> > provides an out :)  The standard says a timer can overrun.
> > If a timer is repeating so fast as to bogdown the system,
> > the code lumps enough of them to unload the system into the
> > overrun count and doesn't take the interrupts.
> >  -g
> 
> (I haven't done my homework and looked in your patch)
> 
> you did notice the bit in posix about repeating timers and how you dont
> reinsert a repeating timer until the signal handler has completed, right?

What the standard says is that only one signal is to be
queued for a given timer.  Subsequent expires of the same
timer then just bump the overrun count.  This is what the
patch does, but still this could overload the timer list and
interrupt code, so in addition to the standard required
overrun stuff, the code checks the next expire time and
fudges a time at least X microseconds from now, where the
time is a multiple (Y) of the repeat time + the current
expire time.  Y is then added to the overrun count to
account for the missing expires.
> 
> that one bit me and we actually had to reimplement portions of our signals
> mechanism to accomodate it.

Yes, the signal code needs to check for that pending timer. 
And NOW (i.e. 2.5) it can be in either the shared list or
the local list or both :(.  This is in the patch.
> 
> that behavior ensures that a POSIX timer can't entirely dominate the system
> (although it certainly can put a hurt on as can any number of other ill
> advised programming blunders)

I would be open to requiring a capability to run the repeat
time below a fixed value if this would make folks happier. 
It would send the right message to the user, too, i.e. small
repeat counts can be hazardous to your system.
> 
> it however doesn't do anything for kernel things using the timer
> infrastructure....

The interesting thing is that we don't currently have an in
kernel call such as delay, etc.  You just use add_timer(). 
AND none of the possible interfaces I have seen or
considered even hint at needing repeating timers.

-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml

Re: Son of crunch time: the list v1.2.

[Alan Cox]

On Tue, 2002-10-22 at 18:48, Nicholas Wourms wrote:
> Christoph Hellwig wrote:
> > On Tue, Oct 22, 2002 at 01:32:49PM -0400, Nicholas Wourms wrote:
> > 
> >>As was stated by Dave Jones[1], this is something that will probably should 
> >>go in after the freeze.  I'm afraid that having seperate patches is just 
> >>unacceptable.
> > 
> > 
> > If you want your volume manager of choice beein included in 2.6 help to
> > get it in shape quickly.  It's rather simple..
> > 
> 
> Like arguing with a brick wall...

I will agree. I will observe two details
	1. The wall normally wins
	2. Christoph is right

In the mean time it would really help if people took the EVMS/LVM2
debate down to the technical aspects not the marketing ones (at least on
this list). That means fixing the bugs, cleaning up the code, auditing
it etc.

The folks who want to have long rambling discussions rather than fix the
code or test it are encouraged to find a private brick wall, bartender
(or different list) to talk at

Re: Son of crunch time: the list v1.2.

[Nicholas Wourms]

Christoph Hellwig wrote:
> On Tue, Oct 22, 2002 at 01:32:49PM -0400, Nicholas Wourms wrote:
> 
>>As was stated by Dave Jones[1], this is something that will probably should 
>>go in after the freeze.  I'm afraid that having seperate patches is just 
>>unacceptable.
> 
> 
> If you want your volume manager of choice beein included in 2.6 help to
> get it in shape quickly.  It's rather simple..
> 

Like arguing with a brick wall...

Re: Son of crunch time: the list v1.2.

[Christoph Hellwig]

On Tue, Oct 22, 2002 at 01:32:49PM -0400, Nicholas Wourms wrote:
> As was stated by Dave Jones[1], this is something that will probably should 
> go in after the freeze.  I'm afraid that having seperate patches is just 
> unacceptable.

If you want your volume manager of choice beein included in 2.6 help to
get it in shape quickly.  It's rather simple..

Re: Son of crunch time: the list v1.2.

[Nicholas Wourms]

Jeff Garzik wrote:

>>>>10) EVMS (Enterprise Volume Management System) (EVMS team)
>>>>http://sourceforge.net/projects/evms
>>>
>>>Sounds like 2.7.x material, viro pointed out several problems ...
>> 
>> 
>> This one's a problem.  LVM1 is dead, so either LVM2 or EVMS are needed to
>> avoid a major functional regression vs 2.4...
> 
> A political regression only...  if EVMS is not good enough for inclusion
> in mainline, vendors can merge it and/or LVM2 to avoid problems.  _We_
> have higher standards for quality :)  If no LVM is ready for 2.6.x, we
> have no LVM.  It's that simple...  If no one has stepped up to clean up
> LVM1, and LVM2 and EVMS are not ready for inclusion, there's not much we
> can do about it.  That's _not_ a reason to merge crap...
> 

As was stated by Dave Jones[1], this is something that will probably should 
go in after the freeze.  I'm afraid that having seperate patches is just 
unacceptable.  There are many of us out there who use LVM, and I don't 
think it is appropriate to release a kernel without it.  Obviously you 
haven't been paying attention because Joe Thornber has been actively honing 
the device mapper interface over the last couple of weeks.  AFAICT, he has 
addressed all of the issues which were discussed in the critique of his 
code.  Alan's had it in his tree for awhile now, which shows that it is at 
least partially suitable.  When it's ready to go in, I'm sure it'll meet 
your standards.  As for EVMS, I'd consider that a whole different beast.  
Can you mount LVM partitions with using EVMS tools?  We should probably 
keep the two seperate if this is not the case.

Cheers,
Nicholas

[1] http://marc.theaimsgroup.com/?l=linux-kernel&m=103520598902877&w=2

Re: Son of crunch time: the list v1.2.

[Christoph Hellwig]

On Mon, Oct 21, 2002 at 10:02:33PM -0400, Jeff Garzik wrote:
> > 11) Linux Kernel Crash Dumps (Matt Robinson, LKCD team)
> > Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/7060.html
> > Code: http://lkcd.sourceforge.net/
> 
> I would personally _love_ to see this merged, but I think it's 2.7.x 
> material given the recent comments (unless they get fixed up)

The few core changes they make are fine - the rest is purely driver work.
IMHO we should merge the core dump infrastructure (i.e. notifiers,
Kerntypes, etc..) - the rest can be added when ready and before that you
should be able to simply load an externally compiled dump.o anyway..

Re: Son of crunch time: the list v1.2.

[Matt D. Robinson]

On Mon, 21 Oct 2002, Rob Landley wrote:
|>On Monday 21 October 2002 21:02, Jeff Garzik wrote:
|>> Rob Landley wrote:
|>> > 11) Linux Kernel Crash Dumps (Matt Robinson, LKCD team)
|>> > Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/7060.html
|>> > Code: http://lkcd.sourceforge.net/
|>>
|>> I would personally _love_ to see this merged, but I think it's 2.7.x
|>> material given the recent comments (unless they get fixed up)
|>
|>T minus 6 days, and counting... :)

We've incorporated the majority of Christoph's requests, along
with changes requested by a few other developers.  We'll post the
next set later tonight after testing a few SMP/UP/IDE/SCSI crashes
with all of the changes.

There are a couple of things that we didn't change due to the
nature of the project, which I'll first discuss with Christoph
off-line to avoid going down a big rathole. :)  Suffice it to
say that we incorporated almost everything he asked for.

We'll make this deadline.

--Matt

Re: Son of crunch time: the list v1.2.

[Jeff Garzik]

Robert Love wrote:
> I do not think Linus should have the opportunity to turn down any of
> these patches.
> 
> Only one of them has been sent to him, the high-res-timers, and I think
> he should merge it.


um, huh?  Linus's job is to turn down patches...

Re: Son of crunch time: the list v1.2.

[Eric W. Biederman]

Jeff Garzik <jgarzik@pobox.com> writes:

> > 13) Kexec, luanch ELF format linux kernel from Linux (Eric W. Biederman)
> > http://lists.insecure.org/lists/linux-kernel/2002/Oct/6584.html
> 
> Useful, but at the same time not many people will use this I think.  It may need
> to live as a patch for a while, if not for a long while...

Hmm. 2+ years is not enough?

A couple of comments.

The limitation to the ELF file format is long gone, (so the summary is
incorrect).  sys_kexec can launch any random kernel, it just needs an
appropriate user space program that understands the format.  kexec
bzImage works, and I suspect kexec could even start booting windows
from the boot sector of a hard drive.

The code has been looked at, and discussed by the kmonte, and bootimg
authors, and the kexec interface has not been found to be a problem.
Except for tracking kernel interface changes the code really has not
needed to change in quite a long while.

The biggest challenge right now is to track down the strange and
mysterious failures caused by driver or BIOS bugs.  Kexec is
inherently open to a bug anywhere in the system causing it to fail.
The development work consists of writing code, and inventing
techniques to track down those mysterious failures.  Kernel debuggers
don't work when you don't have a running kernel. 

All of this is generic kernel stabilization work, and it sounds to me
like a good complement to the upcoming 2.5.x stabilization efforts.

A smallish user base may be a good argument against it.  But I unless
I have miscounted there are quite a few people playing with bootimg,
and kmonte, not to mention the earlier versions of kexec.  

To do things right sys_kexec needs access to call device_shutdown, and
the reboot notifier chain.  The latter is available only as a  static
variable in kernel/sys.c.  And neither of them are exported from the
kernel.  

Keeping sys_kexec out of the kernel seems to encourage half baked,
half debugged implementations that just work for their authors, and
are limited to what it is easy to do as a module.

Putting in the sys_kexec patch in the kernel will certainly discourage
hacks in the code, and encourage those last few strange mysterious
failures to be tracked.  Plus it will put pressure on driver
maintainers to fix various bugs in their code.  And the patch is
not very intrusive at all so I fail to see a downside except bloat.

Eric

Re: Son of crunch time: the list v1.2.

[george anzinger]

Rob Landley wrote:
> 
> On Monday 21 October 2002 22:20, Robert Love wrote:
> > On Mon, 2002-10-21 at 17:42, Rob Landley wrote:
> 
> > George said he would change the code to meet Linus's issues (re the sub
> > jiffies stuff).  But there was not much debate either way, and I suspect
> > George may in fact be correct.
> 
> Anybody know if he made this change?

Uh, what I will offer is: 
1.) Posix clock & timers  NOT HIGH RES
2.) A three patch set to put in high-res-timers:
   a.) The core kernel timer.c stuff
   b.) The i386 high res stuff
   c.) A patch to increase the POSIX clocks & timers to high
res.
> 
> > George also offered an interface-only version of the patch that
> > implements the POSIX clocks and timers syscalls, without the high
> > resolution support, so it would be nice to at the very least merge the
> > missing POSIX functionality.
> >
> >       Robert Love
> 
> Any comments on which of these three patches Linus should personally have the
> opportunity to turn down after the 27th?
> 
> http://sourceforge.net/projects/high-res-timers

None of them :)  I will post a new set against the latest
kernel.  Working....

-g

-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml

Re: Son of crunch time: the list v1.2.

[george anzinger]

Rob Landley wrote:
> 
> On Monday 21 October 2002 21:02, Jeff Garzik wrote:
> > Rob Landley wrote:
> > > 1) Roman  Zippel's new kernel configuration system.
> > > Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6898.html
> > > Code: http://www.xs4all.nl/~zippel/lc/
> >
> > I support merge, Linus seemed to support it with the caveat that he said
> > he didn't personally see much discussion...
> 
> After CML2, I think everybody's too afraid to speak up. :)
> 
> > > 2) Ted Tso's new ext2/ext3 code with extended attributes and access
> > > control lists.
> > > Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6787.html
> > > Code: bk://extfs.bkbits.net/extfs-2.5-update
> > > http://thunk.org/tytso/linux/extfs-2.5
> >
> > No comment other than I notice tytso's patches got dropped (at least
> > once/twice?).  Maybe viro hasn't reviewed them?
> 
> Reading meaning into Linus dropping patches without explanation is like
> reading meaning into sheep entrails.  (At least with the entrails, you know
> the future is likely to contain mutton.)
> 
> > > 5) VM large page support  (Many people) (in -mm tree)
> > > http://lse.sourceforge.net/
> >
> > Rob - this URL doesn't seen to have anything directly to do with large
> > page support.
> 
> I got the URL straight from Guillaume's list.  Haven't looked at it.  I don't
> use Oracle, and the largest box I have immediate access to has maybe 2
> gigabytes of memory in it.  (256 megs is pretty standard 'round here...)
> 
> > > 6) Page table sharing  (Daniel Phillips, Dave McCracken) (in -mm tree)
> > > http://www.geocrawler.com/mail/msg.php3?msg_id=7855063&list=35
> > > (A newer version of which seems to be at:)
> > > http://lists.insecure.org/lists/linux-kernel/2002/Oct/6446.html
> >
> > IMO 2.7.x item...
> 
> Yes and no.  Rmap went in already, and this mostly counteracts rmap's main
> downside.  Still, it is cutting it a bit close...
> 
> > > 7) Dynamic Probes (dprobes team)
> > > http://oss.software.ibm.com/developerworks/opensource/linux/projects/dpro
> > >bes
> >
> > why does this need to be the mainline kernel?  this is another type of
> > thing that can live as a patch, IMO...
> 
> Ask IBM. :)
> 
> > > 8) Zerocopy NFS (Hirokazu Takahashi)
> > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0429.html
> >
> > this is already merged, isn't it??
> 
> Another item straight from Guillaume's list...
> 
> > > 9) High resolution timers (George Anzinger, etc.)
> > > http://high-res-timers.sourceforge.net/
> >
> > no comment, I've heard arguments that high-res timers would be useful,
> > but haven't read the patch myself so won't comment...
> 
> I vaguely remember Linus had some objections that it plays with the clock tick
> and potentially penalizes everybody...  Hmmm...
> 
> A quick google comes up with this:
> 
> http://www.cs.helsinki.fi/linux/linux-kernel/2002-28/0360.html

Hm, I had not seen this.  He is right, but the patch
provides an out :)  The standard says a timer can overrun. 
If a timer is repeating so fast as to bogdown the system,
the code lumps enough of them to unload the system into the
overrun count and doesn't take the interrupts.
 -g
> 
> > > 10) EVMS (Enterprise Volume Management System) (EVMS team)
> > > http://sourceforge.net/projects/evms
> >
> > Sounds like 2.7.x material, viro pointed out several problems ...
> 
> This one's a problem.  LVM1 is dead, so either LVM2 or EVMS are needed to
> avoid a major functional regression vs 2.4...
> 
> > > 11) Linux Kernel Crash Dumps (Matt Robinson, LKCD team)
> > > Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/7060.html
> > > Code: http://lkcd.sourceforge.net/
> >
> > I would personally _love_ to see this merged, but I think it's 2.7.x
> > material given the recent comments (unless they get fixed up)
> 
> T minus 6 days, and counting... :)
> 
> > > 12) Rewrite of the console layer (James Simmons)
> > > http://linuxconsole.sourceforge.net/
> >
> > needs more review... but hasn't some of this stuff already made it in?
> > (or am I thinking about fbdev...?)
> 
> This and the page table sharing are probably the two that mean the most to me
> personally, actually.  Not that this is relevant... :)
> 
> > > 13) Kexec, luanch ELF format linux kernel from Linux (Eric W. Biederman)
> > > http://lists.insecure.org/lists/linux-kernel/2002/Oct/6584.html
> >
> > Useful, but at the same time not many people will use this I think.  It
> > may need to live as a patch for a while, if not for a long while...
> 
> I have an odd usage that would be helped by having the linux kernel and a
> ramdisk in the same image, but that's a question of getting support into lilo
> or grub, not the linux kernel itself.  There's probably already a way to do
> it (actually, I'm sure I could if I wanted to hack lilo), it just hasn't made
> it far enough up my to-do list yet...
> 
> > > 14) USAGI IPv6.
> > >
> > > Yoshifuji Hideyaki points out that ipv6 is very important overseas
> > > (where some entire countries make do with a single class B ipv4
> > >
> > > address range).  He says:
> > >>Well, our IPsec is ready, runs and is tested...
> > >>ftp://ftp.linux-ipv6.org/pub/usagi/patch/ipsec/
> >
> > The USAGI guys have been slowly splitting up their patches and
> > submitting them... AFAIK DaveM is just waiting on more split-up IPv6
> > patches from them...
> 
> Okay, ARE the Usagi IPV6 patches and Dave's work dovetailing into one project?
> I'll happily collate them if so, I'd just like to hear it from one of the
> principal authors...
> 
> Rob
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml

Re: Son of crunch time: the list v1.2.

[Robert Love]

On Mon, 2002-10-21 at 20:00, Rob Landley wrote:

> Anybody know if he made this change?

I don't think so.  Its an implementation detail that can be worked out
after the freeze, anyhow.

> Any comments on which of these three patches Linus should
> personally have the opportunity to turn down after the 27th?
> 
> http://sourceforge.net/projects/high-res-timers

I do not think Linus should have the opportunity to turn down any of
these patches.

Only one of them has been sent to him, the high-res-timers, and I think
he should merge it.

	Robert Love

Re: Son of crunch time: the list v1.2.

[Robert Love]

On Mon, 2002-10-21 at 17:42, Rob Landley wrote:

> On Monday 21 October 2002 21:02, Jeff Garzik wrote:
> > Rob Landley wrote:
>
> > > 9) High resolution timers (George Anzinger, etc.)
> > > http://high-res-timers.sourceforge.net/
> >
> > no comment, I've heard arguments that high-res timers would be useful,
> > but haven't read the patch myself so won't comment...
> 
> I vaguely remember Linus had some objections that it plays with the clock tick 
> and potentially penalizes everybody...  Hmmm...
> 
> A quick google comes up with this:
> 
> http://www.cs.helsinki.fi/linux/linux-kernel/2002-28/0360.html

George said he would change the code to meet Linus's issues (re the sub
jiffies stuff).  But there was not much debate either way, and I suspect
George may in fact be correct.

George also offered an interface-only version of the patch that
implements the POSIX clocks and timers syscalls, without the high
resolution support, so it would be nice to at the very least merge the
missing POSIX functionality.

	Robert Love

Re: Son of crunch time: the list v1.2.

[Karim Yaghmour]

Jeff Garzik wrote:
> > 3) Linux Trace Toolkit (LTT) (Karim Yaghmour)
> > Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/7016.html
> > Patch:
> > http://opersys.com/ftp/pub/LTT/ExtraPatches/patch-ltt-linux-2.5.44-vanilla-021019-2.2.bz2
> > User tools: http://opersys.com/ftp/pub/LTT/TraceToolkit-0.9.6pre2.tgz
> 
> I dunno if this needs to be in the kernel...

We've had this debate with a couple of folks before, most notably with
Ingo Molnar. Here was the essence of my reply to Ingo then:
http://marc.theaimsgroup.com/?l=linux-kernel&m=103272155416405&w=2
Ingo went on to provide us with a to-do list which we've complied with
100%.

Basically, there are plent of day-to-day user needs which LTT fills
perfectly. We don't expect users to recompile their kernel in order
to use a symbolic debugger and I don't see why users should need to
recompile their kernel to:
- solve complex inter-process interactions
- obtain exact measures regarding kernel vs. app time
- understand the exact dynamic interaction between their app, the
kernel and all the other processes running on the system.
- etc.

Here was Linus' take:
> I suspect we'll want to have some form of event tracing eventually, but
> I'm personally pretty convinced that it needs to be a per-CPU thing, and 
> the core mechanism would need to be very lightweight.
From:
http://marc.theaimsgroup.com/?l=linux-kernel&m=103271992115305&w=2

As I explained at that time to Linus, these are exactly the features we
are looking for in LTT. And since that posting, we've added precisely
those features (as I had promissed Linus, must I add), among many others
requested by folks on the LKML. If there's something we've missed, I'm
all ears.

Karim

===================================================
                 Karim Yaghmour
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

Re: Son of crunch time: the list v1.2.

[Arnaldo Carvalho de Melo]

Em Mon, Oct 21, 2002 at 10:53:03PM -0400, Jeff Garzik escreveu:
> >Okay, ARE the Usagi IPV6 patches and Dave's work dovetailing into one 
> >project?  I'll happily collate them if so, I'd just like to hear it from 
> >one of the principal authors...

> I'm sure he can elaborate, but AFAIK DaveM and Alexey are only doing 
> IPSEC... where USAGI and IPSEC intersect, there will be clashes.  So if 
> USAGI is waiting on IPSEC to submit more patches, things are waiting on 
> DaveM.  But if there are IPSEC-independent patches, USAGI should go 
> ahead and send them :)

They are sending it, and David already stated here that he will be using some
pieces of USAGI's ipsec work, but the core is being coded by him and Alexey.

- Arnaldo

Re: Son of crunch time: the list v1.2.

[Jeff Garzik]

Rob Landley wrote:
> On Monday 21 October 2002 21:02, Jeff Garzik wrote:
>>>8) Zerocopy NFS (Hirokazu Takahashi)
>>>http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0429.html
>>
>>this is already merged, isn't it??
> 
> 
> Another item straight from Guillaume's list...

You can remove this item...


>>>10) EVMS (Enterprise Volume Management System) (EVMS team)
>>>http://sourceforge.net/projects/evms
>>
>>Sounds like 2.7.x material, viro pointed out several problems ...
> 
> 
> This one's a problem.  LVM1 is dead, so either LVM2 or EVMS are needed to 
> avoid a major functional regression vs 2.4...

A political regression only...  if EVMS is not good enough for inclusion 
in mainline, vendors can merge it and/or LVM2 to avoid problems.  _We_ 
have higher standards for quality :)  If no LVM is ready for 2.6.x, we 
have no LVM.  It's that simple...  If no one has stepped up to clean up 
LVM1, and LVM2 and EVMS are not ready for inclusion, there's not much we 
can do about it.  That's _not_ a reason to merge crap...


>>>14) USAGI IPv6.
>>>
>>>Yoshifuji Hideyaki points out that ipv6 is very important overseas
>>>(where some entire countries make do with a single class B ipv4
>>>
>>>address range).  He says:
>>>
>>>>Well, our IPsec is ready, runs and is tested...
>>>>ftp://ftp.linux-ipv6.org/pub/usagi/patch/ipsec/
>>>
>>The USAGI guys have been slowly splitting up their patches and
>>submitting them... AFAIK DaveM is just waiting on more split-up IPv6
>>patches from them...
> 
> 
> Okay, ARE the Usagi IPV6 patches and Dave's work dovetailing into one project?  
> I'll happily collate them if so, I'd just like to hear it from one of the 
> principal authors...


I'm sure he can elaborate, but AFAIK DaveM and Alexey are only doing 
IPSEC... where USAGI and IPSEC intersect, there will be clashes.  So if 
USAGI is waiting on IPSEC to submit more patches, things are waiting on 
DaveM.  But if there are IPSEC-independent patches, USAGI should go 
ahead and send them :)

	Jeff

Re: Son of crunch time: the list v1.2.

[Martin J. Bligh]

>> 5) VM large page support  (Many people) (in -mm tree)
>> http://lse.sourceforge.net/
> 
> Rob - this URL doesn't seen to have anything directly to do with large page support.
> 
> Others-
> Is this not already in the kernel?  I still want to actually see someone from Oracle actually say "I will use this" or "we find this useful".
> 
> [I cynically propose a sys_oracle and be done with it <g>]

Oracle are not the only users of this, nor the only database in
the world (though they often think they are) ;-)

There is *something* in the kernel ... whether it's useful or not
is a matter of opinion - what we see as remaining to do is to 
provide hooks for generic interfaces (eg shmem, mmap, sbrk).
 
>> 6) Page table sharing  (Daniel Phillips, Dave McCracken) (in -mm tree)
>> http://www.geocrawler.com/mail/msg.php3?msg_id=7855063&list=35
>> (A newer version of which seems to be at:)
>> http://lists.insecure.org/lists/linux-kernel/2002/Oct/6446.html
> 
> IMO 2.7.x item...

Would be if it wasn't needed to alleviate all the overhead incurred
by rmap. As it is, the extra ZONE_NORMAL load kills large boxes dead ;-( 
Will provide speedups for the fork+exec cycle for the low end too.

M.

Re: Son of crunch time: the list v1.2.

[Jeff Garzik]

Rob Landley wrote:
> 1) Roman  Zippel's new kernel configuration system.
> Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6898.html
> Code: http://www.xs4all.nl/~zippel/lc/

I support merge, Linus seemed to support it with the caveat that he said 
he didn't personally see much discussion...


> 2) Ted Tso's new ext2/ext3 code with extended attributes and access control
> lists.
> Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6787.html
> Code: bk://extfs.bkbits.net/extfs-2.5-update 
> http://thunk.org/tytso/linux/extfs-2.5

No comment other than I notice tytso's patches got dropped (at least 
once/twice?).  Maybe viro hasn't reviewed them?

IIRC viro had some objections to ACLs in general and how they might not 
necessarily actually improve security -- but I did not see detailed 
elaboration on this.


> 3) Linux Trace Toolkit (LTT) (Karim Yaghmour)
> Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/7016.html
> Patch: 
> http://opersys.com/ftp/pub/LTT/ExtraPatches/patch-ltt-linux-2.5.44-vanilla-021019-2.2.bz2
> User tools: http://opersys.com/ftp/pub/LTT/TraceToolkit-0.9.6pre2.tgz

I dunno if this needs to be in the kernel...


> 4) Device mapper for Logical Volume Manager (LVM2)  (LVM2 team)  (in -ac tree)
> http://www.sistina.com/products_lvm.htm

Needs sysfs support or devmapperfs support... no need to add a bunch of 
ioctls that will go away eventually.


> 5) VM large page support  (Many people) (in -mm tree)
> http://lse.sourceforge.net/

Rob - this URL doesn't seen to have anything directly to do with large 
page support.

Others-
Is this not already in the kernel?  I still want to actually see someone 
from Oracle actually say "I will use this" or "we find this useful".

[I cynically propose a sys_oracle and be done with it <g>]


> 6) Page table sharing  (Daniel Phillips, Dave McCracken) (in -mm tree)
> http://www.geocrawler.com/mail/msg.php3?msg_id=7855063&list=35
> (A newer version of which seems to be at:)
> http://lists.insecure.org/lists/linux-kernel/2002/Oct/6446.html

IMO 2.7.x item...


> 7) Dynamic Probes (dprobes team)
> http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes

why does this need to be the mainline kernel?  this is another type of 
thing that can live as a patch, IMO...


> 8) Zerocopy NFS (Hirokazu Takahashi)
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0429.html

this is already merged, isn't it??


> 9) High resolution timers (George Anzinger, etc.)
> http://high-res-timers.sourceforge.net/

no comment, I've heard arguments that high-res timers would be useful, 
but haven't read the patch myself so won't comment...


> 10) EVMS (Enterprise Volume Management System) (EVMS team)
> http://sourceforge.net/projects/evms

Sounds like 2.7.x material, viro pointed out several problems ...


> 11) Linux Kernel Crash Dumps (Matt Robinson, LKCD team)
> Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/7060.html
> Code: http://lkcd.sourceforge.net/

I would personally _love_ to see this merged, but I think it's 2.7.x 
material given the recent comments (unless they get fixed up)


> 12) Rewrite of the console layer (James Simmons)
> http://linuxconsole.sourceforge.net/

needs more review... but hasn't some of this stuff already made it in?
(or am I thinking about fbdev...?)

> 13) Kexec, luanch ELF format linux kernel from Linux (Eric W. Biederman)
> http://lists.insecure.org/lists/linux-kernel/2002/Oct/6584.html

Useful, but at the same time not many people will use this I think.  It 
may need to live as a patch for a while, if not for a long while...


> 14) USAGI IPv6.
> 
> Yoshifuji Hideyaki points out that ipv6 is very important overseas
> (where some entire countries make do with a single class B ipv4
> address range).  He says:
> 
> 
>>Well, our IPsec is ready, runs and is tested...
>>ftp://ftp.linux-ipv6.org/pub/usagi/patch/ipsec/

The USAGI guys have been slowly splitting up their patches and 
submitting them... AFAIK DaveM is just waiting on more split-up IPv6 
patches from them...


> 17) Kernel Hooks (IBM kernel team, contact: Richard J. Moore.)
> http://www-124.ibm.com/linux/projects/kernelhooks/

at first glance this seems to have serious issues with being a black 
hole for overriding syscalls-type behavior...


> 19) In-kernel module loader (Rusty Russell.)
> http://lists.insecure.org/lists/linux-kernel/2002/Oct/6214.html

most likely 2.7.x material

> 20) Unlimited groups patch (Tim Hockin.)

I dunno if people want to take the hit in the mainline kernel... Maybe 
this should be a CONFIG_xxx option, or live outside as a patch that 
enterprise customers integrate



> 8) ReiserFS 4
> 
> Hans Reiser said:
> 
> 
>>We will send Reiser4 out soon, probably around the 27th.

how mysterious...  ;-)

Re: Son of crunch time: the list v1.2.

[Davide Libenzi]

On Mon, 21 Oct 2002, Rob Landley wrote:

> 16) sys_epoll (Davide Libenzi)
> homepage: http://www.xmailserver.org/linux-patches/nio-improve.html
> patch: http://www.xmailserver.org/linux-patches/sys_epoll-2.5.44-0.3.diff

http://www.xmailserver.org/linux-patches/sys_epoll-2.5.44-0.5.diff



- Davide

Re: Son of crunch time: the list v1.2.

[Rob Landley]

On Monday 21 October 2002 21:02, Jeff Garzik wrote:
> Rob Landley wrote:
> > 1) Roman  Zippel's new kernel configuration system.
> > Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6898.html
> > Code: http://www.xs4all.nl/~zippel/lc/
>
> I support merge, Linus seemed to support it with the caveat that he said
> he didn't personally see much discussion...

After CML2, I think everybody's too afraid to speak up. :)

> > 2) Ted Tso's new ext2/ext3 code with extended attributes and access
> > control lists.
> > Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6787.html
> > Code: bk://extfs.bkbits.net/extfs-2.5-update
> > http://thunk.org/tytso/linux/extfs-2.5
>
> No comment other than I notice tytso's patches got dropped (at least
> once/twice?).  Maybe viro hasn't reviewed them?

Reading meaning into Linus dropping patches without explanation is like 
reading meaning into sheep entrails.  (At least with the entrails, you know 
the future is likely to contain mutton.)

> > 5) VM large page support  (Many people) (in -mm tree)
> > http://lse.sourceforge.net/
>
> Rob - this URL doesn't seen to have anything directly to do with large
> page support.

I got the URL straight from Guillaume's list.  Haven't looked at it.  I don't 
use Oracle, and the largest box I have immediate access to has maybe 2 
gigabytes of memory in it.  (256 megs is pretty standard 'round here...)

> > 6) Page table sharing  (Daniel Phillips, Dave McCracken) (in -mm tree)
> > http://www.geocrawler.com/mail/msg.php3?msg_id=7855063&list=35
> > (A newer version of which seems to be at:)
> > http://lists.insecure.org/lists/linux-kernel/2002/Oct/6446.html
>
> IMO 2.7.x item...

Yes and no.  Rmap went in already, and this mostly counteracts rmap's main 
downside.  Still, it is cutting it a bit close...

> > 7) Dynamic Probes (dprobes team)
> > http://oss.software.ibm.com/developerworks/opensource/linux/projects/dpro
> >bes
>
> why does this need to be the mainline kernel?  this is another type of
> thing that can live as a patch, IMO...

Ask IBM. :)

> > 8) Zerocopy NFS (Hirokazu Takahashi)
> > http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0429.html
>
> this is already merged, isn't it??

Another item straight from Guillaume's list...

> > 9) High resolution timers (George Anzinger, etc.)
> > http://high-res-timers.sourceforge.net/
>
> no comment, I've heard arguments that high-res timers would be useful,
> but haven't read the patch myself so won't comment...

I vaguely remember Linus had some objections that it plays with the clock tick 
and potentially penalizes everybody...  Hmmm...

A quick google comes up with this:

http://www.cs.helsinki.fi/linux/linux-kernel/2002-28/0360.html

> > 10) EVMS (Enterprise Volume Management System) (EVMS team)
> > http://sourceforge.net/projects/evms
>
> Sounds like 2.7.x material, viro pointed out several problems ...

This one's a problem.  LVM1 is dead, so either LVM2 or EVMS are needed to 
avoid a major functional regression vs 2.4...

> > 11) Linux Kernel Crash Dumps (Matt Robinson, LKCD team)
> > Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/7060.html
> > Code: http://lkcd.sourceforge.net/
>
> I would personally _love_ to see this merged, but I think it's 2.7.x
> material given the recent comments (unless they get fixed up)

T minus 6 days, and counting... :)

> > 12) Rewrite of the console layer (James Simmons)
> > http://linuxconsole.sourceforge.net/
>
> needs more review... but hasn't some of this stuff already made it in?
> (or am I thinking about fbdev...?)

This and the page table sharing are probably the two that mean the most to me 
personally, actually.  Not that this is relevant... :)

> > 13) Kexec, luanch ELF format linux kernel from Linux (Eric W. Biederman)
> > http://lists.insecure.org/lists/linux-kernel/2002/Oct/6584.html
>
> Useful, but at the same time not many people will use this I think.  It
> may need to live as a patch for a while, if not for a long while...

I have an odd usage that would be helped by having the linux kernel and a 
ramdisk in the same image, but that's a question of getting support into lilo 
or grub, not the linux kernel itself.  There's probably already a way to do 
it (actually, I'm sure I could if I wanted to hack lilo), it just hasn't made 
it far enough up my to-do list yet...

> > 14) USAGI IPv6.
> >
> > Yoshifuji Hideyaki points out that ipv6 is very important overseas
> > (where some entire countries make do with a single class B ipv4
> >
> > address range).  He says:
> >>Well, our IPsec is ready, runs and is tested...
> >>ftp://ftp.linux-ipv6.org/pub/usagi/patch/ipsec/
>
> The USAGI guys have been slowly splitting up their patches and
> submitting them... AFAIK DaveM is just waiting on more split-up IPv6
> patches from them...

Okay, ARE the Usagi IPV6 patches and Dave's work dovetailing into one project?  
I'll happily collate them if so, I'd just like to hear it from one of the 
principal authors...

Rob

Son of crunch time: the list v1.2.

[Rob Landley]

Linus returns from the Linux Lunacy Cruise after Sunday, October 27th.  The
following features aim to be ready for submission to Linus by Monday, October
28th, to be considered for inclusion (in 2.5.45) before the feature freeze on
Thursday, October 31 (halloween).

Note: if you want to submit a new entry to this list, PLEASE provide a URL
to where the patch can be found, and any descriptive announcement you think
useful (user space tools, etc).  This doesn't have to be a web page devoted
to the patch, if the patch has been posted to linux-kernel a URL to the post
on any linux-kernel archive site should  be fine.

If you don't know of one, a good site for looking at a threaded version of the 
linux-kernel archive is http://lists.insecure.org/lists/linux-kernel/
and a keyword searchable archive is available at:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=mlist.linux.kernel

This list is just pending features trying to get in before feature freeze.
If you want to know what's already gone in, or what's being worked on for
the next development cycle, check out "http://kernelnewbies.org/status".

And now, in no particular order:

============================ Pending features: =============================

1) Roman  Zippel's new kernel configuration system.
Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6898.html
Code: http://www.xs4all.nl/~zippel/lc/

2) Ted Tso's new ext2/ext3 code with extended attributes and access control
lists.
Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6787.html
Code: bk://extfs.bkbits.net/extfs-2.5-update 
http://thunk.org/tytso/linux/extfs-2.5

Andreas Dilger says ext3 EA+ACL is now in the -mm tree.

3) Linux Trace Toolkit (LTT) (Karim Yaghmour)
Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/7016.html
Patch: 
http://opersys.com/ftp/pub/LTT/ExtraPatches/patch-ltt-linux-2.5.44-vanilla-021019-2.2.bz2
User tools: http://opersys.com/ftp/pub/LTT/TraceToolkit-0.9.6pre2.tgz

4) Device mapper for Logical Volume Manager (LVM2)  (LVM2 team)  (in -ac tree)
http://www.sistina.com/products_lvm.htm

5) VM large page support  (Many people) (in -mm tree)
http://lse.sourceforge.net/

6) Page table sharing  (Daniel Phillips, Dave McCracken) (in -mm tree)
http://www.geocrawler.com/mail/msg.php3?msg_id=7855063&list=35
(A newer version of which seems to be at:)
http://lists.insecure.org/lists/linux-kernel/2002/Oct/6446.html

7) Dynamic Probes (dprobes team)
http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes

8) Zerocopy NFS (Hirokazu Takahashi)
http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0429.html

9) High resolution timers (George Anzinger, etc.)
http://high-res-timers.sourceforge.net/

10) EVMS (Enterprise Volume Management System) (EVMS team)
http://sourceforge.net/projects/evms

11) Linux Kernel Crash Dumps (Matt Robinson, LKCD team)
Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/7060.html
Code: http://lkcd.sourceforge.net/

12) Rewrite of the console layer (James Simmons)
http://linuxconsole.sourceforge.net/

13) Kexec, luanch ELF format linux kernel from Linux (Eric W. Biederman)
http://lists.insecure.org/lists/linux-kernel/2002/Oct/6584.html

14) USAGI IPv6.

Yoshifuji Hideyaki points out that ipv6 is very important overseas
(where some entire countries make do with a single class B ipv4
address range).  He says:

> Well, our IPsec is ready, runs and is tested...
> ftp://ftp.linux-ipv6.org/pub/usagi/patch/ipsec/

15) MMU-less processor support (Greg Ungerer)
http://lists.insecure.org/lists/linux-kernel/2002/Oct/7027.html

16) sys_epoll (Davide Libenzi)
homepage: http://www.xmailserver.org/linux-patches/nio-improve.html
patch: http://www.xmailserver.org/linux-patches/sys_epoll-2.5.44-0.3.diff

17) Kernel Hooks (IBM kernel team, contact: Richard J. Moore.)
http://www-124.ibm.com/linux/projects/kernelhooks/

18) CD Recording/sgio patches (Jens Axboe)
http://www.kernel.org/pub/linux/kernel/people/axboe/patches/v2.5/2.5.44/

19) In-kernel module loader (Rusty Russell.)
http://lists.insecure.org/lists/linux-kernel/2002/Oct/6214.html

20) Unlimited groups patch (Tim Hockin.)

Older (unified) version:
http://lists.insecure.org/lists/linux-kernel/2002/Oct/1619.html

Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/3885.html
Patch set:
http://lists.insecure.org/lists/linux-kernel/2002/Oct/3884.html
http://lists.insecure.org/lists/linux-kernel/2002/Oct/3886.html
http://lists.insecure.org/lists/linux-kernel/2002/Oct/3888.html
http://lists.insecure.org/lists/linux-kernel/2002/Oct/3889.html

======================== Unresolved issues: =========================

1) Kernel Probes  (Vamsi Krishna S)

Is this the same as dynamic probes?

2) Unified boot/parameter support (Rusty Russell)
3) Hotplug CPU removal (Rusty Russell)

Patches are available under:

http://www.kernel.org/pub/linux/kernel/people/rusty/patches

But there are a lot of them, and it's not quite clear what to
apply in what order.  (I know Linus likes 'em broken up, but
an description and a pointer to a roll-up patch would be nice
for civilian testers.  I moved the in-kernel module loader to
the main list because I found an announcement posting for it.)

4) hyperthread-aware scheduler
5) connection tracking optimizations.

No URLs to patch.  Anybody want to come out in favor of these
with an announcement and pointer to a specific patch being
suggested for inclusion?

6) IPSEC (David Miller, Alexy)
7) New CryptoAPI (James Morris)

David S. Miller said:

> No URLs, being coded as I type this :-)
>
> Some of the ipv4 infrastructure is in 2.5.44

Note, this may conflict with Yoshifuji Hideyaki's ipv6 ipsec stuff.  If not,
I'd like to collate or clarify the entries.)  USAGI ipv6 is in the first
section and this isn't because I have a URL to an existing patch to
USAGI, and don't for this.

I actually have no idea how much overlap there is between these projects, and 
whether they're considered parts of the same project or to be submitted 
individually...

8) ReiserFS 4

Hans Reiser said:

> We will send Reiser4 out soon, probably around the 27th.
>
> Hans

See also http://www.namesys.com/v4/fast_reiser4.html

Hans and Jens Axboe are arguing about whether or not Reiser4 is a
potential post-freeze addition.  That thread starts here:

http://lists.insecure.org/lists/linux-kernel/2002/Oct/7140.html

9) Administrivia

I need to find a patch-friendly archive that works with "save-as" so
cut and paste doesn't get a chance to mess up whitespace on
patches people have posted to the list a while ago...