headers

headers

[Benny Pedersen]

List-Id: <mlmmj.mmj.dk>
List-Help: <mailto:mlmmj+help@mmj.dk>
List-Post: <mailto:mlmmj@mmj.dk>
List-Subscribe: <mailto:mlmmj+subscribe@mmj.dk>
List-Unsubscribe: <mailto:mlmmj+unsubscribe@mmj.dk>

if thay are added as headers, squirrelmail users would be more happy :-)

since the filter plugin show posting links above mails from a maillist

Precedence: list

would stop vacation scripts from posting holiday msgs to mail lists, if thay are smart to look at the headers

other then that happy new yaer :-)

Re: headers

[Mads Martin Joergensen]

* Benny Pedersen <me@junc.org> [Dec 30. 2005 23:03]:
> List-Id: <mlmmj.mmj.dk>
> List-Help: <mailto:mlmmj+help@mmj.dk>
> List-Post: <mailto:mlmmj@mmj.dk>
> List-Subscribe: <mailto:mlmmj+subscribe@mmj.dk>
> List-Unsubscribe: <mailto:mlmmj+unsubscribe@mmj.dk>
> 
> if thay are added as headers, squirrelmail users would be more happy
> :-)

Just add them to customheaders when configuring your lists, and
squirrelmail users would be happy--I'm a squirrelmail user myself :)

> since the filter plugin show posting links above mails from a maillist
> 
> Precedence: list
> 
> would stop vacation scripts from posting holiday msgs to mail lists,
> if thay are smart to look at the headers

Just add it.

> other then that happy new yaer :-)

Likewise--and hope your christmas holidays went well.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                 -- A. P. J.

Re: headers

[Morten K. Poulsen]

Quoting Mads Martin Joergensen <mmj@mmj.dk>:
> * Benny Pedersen <me@junc.org> [Dec 30. 2005 23:03]:
>> List-Id: <mlmmj.mmj.dk>
>> List-Help: <mailto:mlmmj+help@mmj.dk>
>> List-Post: <mailto:mlmmj@mmj.dk>
>> List-Subscribe: <mailto:mlmmj+subscribe@mmj.dk>
>> List-Unsubscribe: <mailto:mlmmj+unsubscribe@mmj.dk>
>>
>> if thay are added as headers, squirrelmail users would be more happy
>> :-)
>
> Just add them to customheaders when configuring your lists

Umh, Mads Martin... YOU are the list admin of mlmmj@mmj.dk ;-)

Morten

Re: headers

[Mads Martin Joergensen]

* Morten K. Poulsen <morten@afdelingp.dk> [Jan 01. 2006 21:25]:
> >Just add them to customheaders when configuring your lists
> 
> Umh, Mads Martin... YOU are the list admin of mlmmj@mmj.dk ;-)

DUH!

Done.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                 -- A. P. J.

Re: headers

[Christian Laursen]

Mads Martin Joergensen <mmj@mmj.dk> writes:

> * Morten K. Poulsen <morten@afdelingp.dk> [Jan 01. 2006 21:25]:
>> >Just add them to customheaders when configuring your lists
>> 
>> Umh, Mads Martin... YOU are the list admin of mlmmj@mmj.dk ;-)
>
> DUH!
>
> Done.

Argh, and broke my procmail-rule. :)

-- 
Christian Laursen

headers

[Andries.Brouwer]

    From garzik@gtf.org  Mon Aug 18 20:14:47 2003

    I support include/abi, or some other directory that segregates
    user<->kernel shared headers away from kernel-private headers.

    I don't see how that would be auto-generated, though.  Only created
    through lots of hard work :)

Yes, unfortunately. I started doing some of this a few times,
but it is an order of magnitude more work than one thinks at first.
Already the number of include files is very large.
And the fact that it is not just include/abi but involves the architecture
doesn't make life simpler.

No doubt we must first discuss a little bit, but not too much,
the desired directory structure and naming.
Then we must do 5% of the work, and come back to these issues.

In case people actually want to do this, I can coordinate.

In case people want to try just one file, do signal.h.

Andries

Re: headers

[Randy.Dunlap]

On Mon, 18 Aug 2003 21:07:44 +0200 (MEST) Andries.Brouwer@cwi.nl wrote:

|     From garzik@gtf.org  Mon Aug 18 20:14:47 2003
| 
|     I support include/abi, or some other directory that segregates
|     user<->kernel shared headers away from kernel-private headers.
| 
|     I don't see how that would be auto-generated, though.  Only created
|     through lots of hard work :)
| 
| Yes, unfortunately. I started doing some of this a few times,
| but it is an order of magnitude more work than one thinks at first.

I expected that.

| Already the number of include files is very large.
| And the fact that it is not just include/abi but involves the architecture
| doesn't make life simpler.
| 
| No doubt we must first discuss a little bit, but not too much,
| the desired directory structure and naming.
| Then we must do 5% of the work, and come back to these issues.
| 
| In case people actually want to do this, I can coordinate.
| 
| In case people want to try just one file, do signal.h.

Hm, interesting.

Since there are 20+ <arch>/signal.h files and they don't always agree
on signal bit numbers e.g., do we have 20+ abi/arch/signal.h files?
Or 1 abi/signal.h file with many #ifdefs?  ugh.

The ABI is still per-arch, right?  Not _one ABI_ for any/all arches.

Or maybe I'm all wet.

--
~Randy
"Everything is relative."

Re: headers

[Jeff Garzik]

Randy.Dunlap wrote:
> Hm, interesting.
> 
> Since there are 20+ <arch>/signal.h files and they don't always agree
> on signal bit numbers e.g., do we have 20+ abi/arch/signal.h files?
> Or 1 abi/signal.h file with many #ifdefs?  ugh.
> 
> The ABI is still per-arch, right?  Not _one ABI_ for any/all arches.


Correct.  So there would be an include/abi/i386 or include/abi/arch/i386 
or whatever, in addition to regular 'ole include/abi.  Or maybe 
include/asm-$arch/abi.  Take your pick :)  Arch separation is definitely 
a requirement, as you guessed.

	Jeff

Re: headers

[Andries Brouwer]

On Mon, Aug 18, 2003 at 02:57:09PM -0700, Randy.Dunlap wrote:
> | In case people want to try just one file, do signal.h.
> 
> Since there are 20+ <arch>/signal.h files and they don't always agree
> on signal bit numbers e.g., do we have 20+ abi/arch/signal.h files?
> Or 1 abi/signal.h file with many #ifdefs?  ugh.
> 
> The ABI is still per-arch, right?  Not _one ABI_ for any/all arches.

Yes, per arch.

Re: headers

[H. Peter Anvin]

Followup to:  <UTC200308181907.h7IJ7im12407.aeb@smtp.cwi.nl>
By author:    Andries.Brouwer@cwi.nl
In newsgroup: linux.dev.kernel
>
>     From garzik@gtf.org  Mon Aug 18 20:14:47 2003
> 
>     I support include/abi, or some other directory that segregates
>     user<->kernel shared headers away from kernel-private headers.
> 
>     I don't see how that would be auto-generated, though.  Only created
>     through lots of hard work :)
> 
> Yes, unfortunately. I started doing some of this a few times,
> but it is an order of magnitude more work than one thinks at first.
> Already the number of include files is very large.
> And the fact that it is not just include/abi but involves the architecture
> doesn't make life simpler.
> 
> No doubt we must first discuss a little bit, but not too much,
> the desired directory structure and naming.
> Then we must do 5% of the work, and come back to these issues.
> 
> In case people actually want to do this, I can coordinate.
> 
> In case people want to try just one file, do signal.h.
> 

Oh yes, this is a whole lot of work.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: headers

[Rob Landley]

On Monday 18 August 2003 21:45, H. Peter Anvin wrote:
> Followup to:  <UTC200308181907.h7IJ7im12407.aeb@smtp.cwi.nl>
> By author:    Andries.Brouwer@cwi.nl
> In newsgroup: linux.dev.kernel
>
> >     From garzik@gtf.org  Mon Aug 18 20:14:47 2003
> >
> >     I support include/abi, or some other directory that segregates
> >     user<->kernel shared headers away from kernel-private headers.
> >
> >     I don't see how that would be auto-generated, though.  Only created
> >     through lots of hard work :)
> >
> > Yes, unfortunately. I started doing some of this a few times,
> > but it is an order of magnitude more work than one thinks at first.
> > Already the number of include files is very large.
> > And the fact that it is not just include/abi but involves the
> > architecture doesn't make life simpler.
> >
> > No doubt we must first discuss a little bit, but not too much,
> > the desired directory structure and naming.
> > Then we must do 5% of the work, and come back to these issues.
> >
> > In case people actually want to do this, I can coordinate.
> >
> > In case people want to try just one file, do signal.h.
>
> Oh yes, this is a whole lot of work.

But is it 2.6 work, or 2.8 work?

Rob

Re: headers

[Randy.Dunlap]

On Tue, 19 Aug 2003 08:55:06 -0400 Rob Landley <rob@landley.net> wrote:

| On Monday 18 August 2003 21:45, H. Peter Anvin wrote:
| > Followup to:  <UTC200308181907.h7IJ7im12407.aeb@smtp.cwi.nl>
| > By author:    Andries.Brouwer@cwi.nl
| > In newsgroup: linux.dev.kernel
| >
| > >     From garzik@gtf.org  Mon Aug 18 20:14:47 2003
| > >
| > >     I support include/abi, or some other directory that segregates
| > >     user<->kernel shared headers away from kernel-private headers.
| > >
| > >     I don't see how that would be auto-generated, though.  Only created
| > >     through lots of hard work :)
| > >
| > > Yes, unfortunately. I started doing some of this a few times,
| > > but it is an order of magnitude more work than one thinks at first.
| > > Already the number of include files is very large.
| > > And the fact that it is not just include/abi but involves the
| > > architecture doesn't make life simpler.
| > >
| > > No doubt we must first discuss a little bit, but not too much,
| > > the desired directory structure and naming.
| > > Then we must do 5% of the work, and come back to these issues.
| > >
| > > In case people actually want to do this, I can coordinate.
| > >
| > > In case people want to try just one file, do signal.h.
| >
| > Oh yes, this is a whole lot of work.
| 
| But is it 2.6 work, or 2.8 work?

I think that we are currently discussing it as 2.7 work.

--
~Randy
"Everything is relative."