I accidentally enabled libata config options on my Sun Ultra 1 (sparc64,
UP, no PCI, only SBUS):
MODPOST 440 modules
ERROR: "dma_unmap_sg" [drivers/ata/libata.ko] undefined!
ERROR: "dma_map_sg" [drivers/ata/libata.ko] undefined!
ERROR: "dma_unmap_single" [drivers/ata/libata.ko] undefined!
ERROR: "dma_mapping_error" [drivers/ata/libata.ko] undefined!
ERROR: "dma_map_single" [drivers/ata/libata.ko] undefined!
CONFIG_PCI=n
CONFIG_ATA=m
This seems to be a valid configuration since libata can drive non-PCI
devices too?
--
Meelis Roos ([email protected])
From: Meelis Roos <[email protected]>
Date: Sun, 3 Jun 2007 23:23:33 +0300 (EEST)
> I accidentally enabled libata config options on my Sun Ultra 1 (sparc64,
> UP, no PCI, only SBUS):
>
> MODPOST 440 modules
> ERROR: "dma_unmap_sg" [drivers/ata/libata.ko] undefined!
> ERROR: "dma_map_sg" [drivers/ata/libata.ko] undefined!
> ERROR: "dma_unmap_single" [drivers/ata/libata.ko] undefined!
> ERROR: "dma_mapping_error" [drivers/ata/libata.ko] undefined!
> ERROR: "dma_map_single" [drivers/ata/libata.ko] undefined!
>
> CONFIG_PCI=n
> CONFIG_ATA=m
>
> This seems to be a valid configuration since libata can drive non-PCI
> devices too?
It really makes no sense to allow this on Sparc, there are no
non-PCI Sparc ATA controllers.
Therefore I'll fix it like this:
commit 6274b5c63131c3110405db5d19e71af26cbbd375
Author: David S. Miller <[email protected]>
Date: Sun Jun 3 17:39:56 2007 -0700
[ATA]: Don't allow to enable this for SPARC64 without PCI.
Based upon a report from Meelis Roos.
Signed-off-by: David S. Miller <[email protected]>
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index b4a8d60..7d893a6 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -8,6 +8,7 @@ menuconfig ATA
depends on BLOCK
depends on !(M32R || M68K) || BROKEN
depends on !SUN4 || BROKEN
+ depends on !(SPARC64 && !PCI)
select SCSI
---help---
If you want to use a ATA hard disk, ATA tape drive, ATA CD-ROM or
On Sun, Jun 03, 2007 at 05:40:10PM -0700, David Miller wrote:
> From: Meelis Roos <[email protected]>
> Date: Sun, 3 Jun 2007 23:23:33 +0300 (EEST)
>
> > I accidentally enabled libata config options on my Sun Ultra 1 (sparc64,
> > UP, no PCI, only SBUS):
> >
> > MODPOST 440 modules
> > ERROR: "dma_unmap_sg" [drivers/ata/libata.ko] undefined!
> > ERROR: "dma_map_sg" [drivers/ata/libata.ko] undefined!
> > ERROR: "dma_unmap_single" [drivers/ata/libata.ko] undefined!
> > ERROR: "dma_mapping_error" [drivers/ata/libata.ko] undefined!
> > ERROR: "dma_map_single" [drivers/ata/libata.ko] undefined!
> >
> > CONFIG_PCI=n
> > CONFIG_ATA=m
> >
> > This seems to be a valid configuration since libata can drive non-PCI
> > devices too?
>
> It really makes no sense to allow this on Sparc, there are no
> non-PCI Sparc ATA controllers.
>
> Therefore I'll fix it like this:
The right fix is the depend on the new HAS_DMA (or whatever it's called)
symbol. The proper long-term fix is to move calln to the dam mapping
functions from the core libata files into the drivers responsibility with
a default implementation for the typical cases.
>
> commit 6274b5c63131c3110405db5d19e71af26cbbd375
> Author: David S. Miller <[email protected]>
> Date: Sun Jun 3 17:39:56 2007 -0700
>
> [ATA]: Don't allow to enable this for SPARC64 without PCI.
>
> Based upon a report from Meelis Roos.
>
> Signed-off-by: David S. Miller <[email protected]>
>
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index b4a8d60..7d893a6 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -8,6 +8,7 @@ menuconfig ATA
> depends on BLOCK
> depends on !(M32R || M68K) || BROKEN
> depends on !SUN4 || BROKEN
> + depends on !(SPARC64 && !PCI)
> select SCSI
> ---help---
> If you want to use a ATA hard disk, ATA tape drive, ATA CD-ROM or
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
---end quoted text---
[ Your email has `m68k' in the body, so I read it :-]
On Sun, 3 Jun 2007, David Miller wrote:
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index b4a8d60..7d893a6 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -8,6 +8,7 @@ menuconfig ATA
> depends on BLOCK
> depends on !(M32R || M68K) || BROKEN
> depends on !SUN4 || BROKEN
> + depends on !(SPARC64 && !PCI)
> select SCSI
Isn't `!SPARC64 || PCI' more readable?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
> > CONFIG_PCI=n
> > CONFIG_ATA=m
> >
> > This seems to be a valid configuration since libata can drive non-PCI
> > devices too?
Yep.
> It really makes no sense to allow this on Sparc, there are no
> non-PCI Sparc ATA controllers.
There are PCMCIA controllers and PCI/PCMCIA/Cardbus adapters for the
Sparc platform I thought ?
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index b4a8d60..7d893a6 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -8,6 +8,7 @@ menuconfig ATA
> depends on BLOCK
> depends on !(M32R || M68K) || BROKEN
> depends on !SUN4 || BROKEN
> + depends on !(SPARC64 && !PCI)
NAK - this is the wrong approach. PCI=n ATA=m should compile. Sparc is
not the only problem case. The DMA handling bits of libata are fairly
nicely split out but they are stuck in the same file and unconditionally
compiled in.
I'll have a poke at this when I get a bit of time if Jeff doesn't.
Alan
From: Alan Cox <[email protected]>
Date: Mon, 4 Jun 2007 14:30:05 +0100
> > It really makes no sense to allow this on Sparc, there are no
> > non-PCI Sparc ATA controllers.
>
> There are PCMCIA controllers and PCI/PCMCIA/Cardbus adapters for the
> Sparc platform I thought ?
The 32-bit sparc port has some but those PCMCIA controllers aren't
going to be supported in the foreseeable future, you have to abstract
out all the inb/outb etc. operations to go through the pcmcia
controller driver for one thing.
Secondarily, sparc32 lacks an active maintainer and it's
been like this for several years, the only things getting
worked on therefore are basica functionality and the most
important bug fixes.
On Mon, Jun 04, 2007 at 08:47:19AM +0100, Christoph Hellwig wrote:
> The right fix is the depend on the new HAS_DMA (or whatever it's called)
ACK... if the platform truly does not do DMA.
> symbol. The proper long-term fix is to move calln to the dam mapping
> functions from the core libata files into the drivers responsibility with
> a default implementation for the typical cases.
NAK
We have generic devices and generic DMA mapping. libata already uses
the generic stuff. Now fix the platform...
Jeff
From: Alan Cox <[email protected]>
Date: Mon, 4 Jun 2007 14:30:05 +0100
>> There are PCMCIA controllers and PCI/PCMCIA/Cardbus adapters for the
>> Sparc platform I thought ?
On Mon, Jun 04, 2007 at 02:22:43PM -0700, David Miller wrote:
> The 32-bit sparc port has some but those PCMCIA controllers aren't
> going to be supported in the foreseeable future, you have to abstract
> out all the inb/outb etc. operations to go through the pcmcia
> controller driver for one thing.
> Secondarily, sparc32 lacks an active maintainer and it's
> been like this for several years, the only things getting
> worked on therefore are basica functionality and the most
> important bug fixes.
I don't foresee my ever dealing with those PCMCIA controllers. If by
some miracle I manage to get any work done on basic functionality I'll
consider that having won.
-- wli
> > The 32-bit sparc port has some but those PCMCIA controllers aren't
> > going to be supported in the foreseeable future, you have to abstract
> > out all the inb/outb etc. operations to go through the pcmcia
> > controller driver for one thing.
Thats one place iomap might actually save the day as you can hack in an
ugly "if its this page then go via pcmcia" hack into the io_read8 etc
methods and save the universe.
> I don't foresee my ever dealing with those PCMCIA controllers. If by
> some miracle I manage to get any work done on basic functionality I'll
> consider that having won.
8)
> NAK
>
> We have generic devices and generic DMA mapping. libata already uses
> the generic stuff. Now fix the platform...
Nice theory but your generic helpers rely on the map functions working
even for generic hardware that doesn't need them, so at the very least
there is some clean up required.
On Tue, Jun 05, 2007 at 12:22:18PM +0100, Alan Cox wrote:
> > NAK
> >
> > We have generic devices and generic DMA mapping. libata already uses
> > the generic stuff. Now fix the platform...
>
> Nice theory but your generic helpers rely on the map functions working
> even for generic hardware that doesn't need them, so at the very least
> there is some clean up required.
Sure there is some clean up needed -- on the arch side.
Even !PCI dma_xxx wrappers that do nothing more than return a dma
mapping error are a valid platform implementation.
Even !HAS_DMA (s/390?) arches should be using the aforementioned
return-error wrappers, mimicing the implementation of PCI functions
in linux/pci.h for the !PCI case.
libata core for DMA mapping is already generic enough such that, #ifdefs
are not needed in the code.
OTOH..... further work in libata _is_ need for I/O accessors, to
isolate those from the core code.
Jeff
On Tue, Jun 05, 2007 at 09:56:08AM -0400, Jeff Garzik wrote:
> On Tue, Jun 05, 2007 at 12:22:18PM +0100, Alan Cox wrote:
> > > NAK
> > >
> > > We have generic devices and generic DMA mapping. libata already uses
> > > the generic stuff. Now fix the platform...
> >
> > Nice theory but your generic helpers rely on the map functions working
> > even for generic hardware that doesn't need them, so at the very least
> > there is some clean up required.
>
> Sure there is some clean up needed -- on the arch side.
>
> Even !PCI dma_xxx wrappers that do nothing more than return a dma
> mapping error are a valid platform implementation.
If you don't have DMA capabilities, does libata still need ->pad and
->pad_dma set?
I had a problem where a pata_platform device which wasn't DMA capable
failed to initialise because we quite rightfully made dma_alloc_coherent()
fail (due to the DMA masks not being set.)
It seems odd that libata requires DMA memory for non-DMA capable devices...
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Tue, Jun 05, 2007 at 03:17:14PM +0100, Russell King wrote:
> On Tue, Jun 05, 2007 at 09:56:08AM -0400, Jeff Garzik wrote:
> > On Tue, Jun 05, 2007 at 12:22:18PM +0100, Alan Cox wrote:
> > > > NAK
> > > >
> > > > We have generic devices and generic DMA mapping. libata already uses
> > > > the generic stuff. Now fix the platform...
> > >
> > > Nice theory but your generic helpers rely on the map functions working
> > > even for generic hardware that doesn't need them, so at the very least
> > > there is some clean up required.
> >
> > Sure there is some clean up needed -- on the arch side.
> >
> > Even !PCI dma_xxx wrappers that do nothing more than return a dma
> > mapping error are a valid platform implementation.
>
> If you don't have DMA capabilities, does libata still need ->pad and
> ->pad_dma set?
>
> I had a problem where a pata_platform device which wasn't DMA capable
> failed to initialise because we quite rightfully made dma_alloc_coherent()
> fail (due to the DMA masks not being set.)
>
> It seems odd that libata requires DMA memory for non-DMA capable devices...
Now -that- is a quite valid complaint.
libata needs a bit of work to fall back to PIO-only, if dma_xxx fails.
libata also needs some work to fall back to PIO polling, if IRQ is not
present, or registration fails.
Jeff
BTW, please fix your mailer. It emits Mail-Followup-To headers that
hijack everyone on the thread into the To field, breaking the normal
LKML To/CC standard replying mechanism that has been working for a
decade.
Jeff
On Tue, Jun 05, 2007 at 10:35:23AM -0400, Jeff Garzik wrote:
>
> BTW, please fix your mailer. It emits Mail-Followup-To headers that
> hijack everyone on the thread into the To field, breaking the normal
> LKML To/CC standard replying mechanism that has been working for a
> decade.
Sorry, I will not. My local policy (which I have the utmost right to
have) is that I do not wish to be CC'd on responses to replies to my
posts. Additional useless CC's are a waste of my limited bandwidth
and resources.
It's a question of local policy required by local resource limitations.
So I give you a choice: you can either have the benefit of me reply and
put up with the follow up header, or I will arrange to never reply to
your messages ever again (which may involve me never reading one again).
Which would you prefer?
rmk - who has regular fights with the OOM killer taking out name and
mail servers.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Tue, Jun 05, 2007 at 03:51:49PM +0100, Russell King wrote:
> On Tue, Jun 05, 2007 at 10:35:23AM -0400, Jeff Garzik wrote:
> >
> > BTW, please fix your mailer. It emits Mail-Followup-To headers that
> > hijack everyone on the thread into the To field, breaking the normal
> > LKML To/CC standard replying mechanism that has been working for a
> > decade.
>
> Sorry, I will not. My local policy (which I have the utmost right to
> have) is that I do not wish to be CC'd on responses to replies to my
> posts. Additional useless CC's are a waste of my limited bandwidth
> and resources.
>
> It's a question of local policy required by local resource limitations.
>
> So I give you a choice: you can either have the benefit of me reply and
> put up with the follow up header, or I will arrange to never reply to
> your messages ever again (which may involve me never reading one again).
> Which would you prefer?
Your personal preference is fine with me.
Just stop hijacking -everyone else's- preferences along with it.
A far more community-friendly method that operates within existing email
standards is to filter out duplicate message ids on your side.
Jeff
On Tue, Jun 05, 2007 at 10:56:03AM -0400, Jeff Garzik wrote:
> On Tue, Jun 05, 2007 at 03:51:49PM +0100, Russell King wrote:
> > On Tue, Jun 05, 2007 at 10:35:23AM -0400, Jeff Garzik wrote:
> > >
> > > BTW, please fix your mailer. It emits Mail-Followup-To headers that
> > > hijack everyone on the thread into the To field, breaking the normal
> > > LKML To/CC standard replying mechanism that has been working for a
> > > decade.
> >
> > Sorry, I will not. My local policy (which I have the utmost right to
> > have) is that I do not wish to be CC'd on responses to replies to my
> > posts. Additional useless CC's are a waste of my limited bandwidth
> > and resources.
> >
> > It's a question of local policy required by local resource limitations.
> >
> > So I give you a choice: you can either have the benefit of me reply and
> > put up with the follow up header, or I will arrange to never reply to
> > your messages ever again (which may involve me never reading one again).
> > Which would you prefer?
>
> Your personal preference is fine with me.
>
> Just stop hijacking -everyone else's- preferences along with it.
>
> A far more community-friendly method that operates within existing email
> standards is to filter out duplicate message ids on your side.
Utterly wrong - you didn't understand the problem. Please take the time
to read my email.
It's the fact that I _am_ CC'd on replies, so I get one message from LKML
one from the original poster, maybe one via another mailing list if it's
also copied there. Add that in to the mix of all the other mail hitting
my MTA and the probability for the machine to exhaust it's limited VM is
very high.
Give me a way to stop people CC'ing me on replies and I'll happily remove
the header. Unfortunately there isn't, so I can't.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Tue, Jun 05, 2007 at 03:59:46PM +0100, Russell King wrote:
> It's the fact that I _am_ CC'd on replies, so I get one message from LKML
> one from the original poster, maybe one via another mailing list if it's
> also copied there. Add that in to the mix of all the other mail hitting
> my MTA and the probability for the machine to exhaust it's limited VM is
> very high.
This is an utterly ridiculous argument. You are subscribed to LKML,
with a message size limit of 400K. "replies to rmk" are clearly lost
in the noise compared to the rest of the list traffic.
> Give me a way to stop people CC'ing me on replies and I'll happily remove
> the header. Unfortunately there isn't, so I can't.
So by fiat, you decide that gives you the right to override OTHER
PEOPLE'S personal preferences? Why are you so much more important
to a thread than everyone else?
If you are unwilling to fix the problem and work within existing
community email standards, I think it would be fair to ask vger
postmaster to start excising Mail-Followup-To headers.
You are NOT more important that everyone else.
Stop hijacking EVERYONE ELSE's email preferences.
Jeff
On Tue, Jun 05, 2007 at 11:11:04AM -0400, Jeff Garzik wrote:
> On Tue, Jun 05, 2007 at 03:59:46PM +0100, Russell King wrote:
> > It's the fact that I _am_ CC'd on replies, so I get one message from LKML
> > one from the original poster, maybe one via another mailing list if it's
> > also copied there. Add that in to the mix of all the other mail hitting
> > my MTA and the probability for the machine to exhaust it's limited VM is
> > very high.
>
> This is an utterly ridiculous argument. You are subscribed to LKML,
> with a message size limit of 400K. "replies to rmk" are clearly lost
> in the noise compared to the rest of the list traffic.
Shrug, that's your opinion. My real life experience is some what
different - I'm the one admin'ing these machines so I can see what's
going on.
> > Give me a way to stop people CC'ing me on replies and I'll happily remove
> > the header. Unfortunately there isn't, so I can't.
>
> So by fiat, you decide that gives you the right to override OTHER
> PEOPLE'S personal preferences? Why are you so much more important
> to a thread than everyone else?
Meanwhile you decide that you have a right over _MY_ personal preferences.
It's the same argument I'm afraid, just a different point of view. If
_you_ do not wish to abide by the header then turn off that feature in
your mailer. That's _your_ preference and one which _you_ can set.
> If you are unwilling to fix the problem and work within existing
> community email standards, I think it would be fair to ask vger
> postmaster to start excising Mail-Followup-To headers.
Well, that will leave me with _no_ _choice_ but to arrange for the
SMTP MAIL FROM from others to receive a 550 error code to remove
the problem. Is that really what you'd like me to do?
> You are NOT more important that everyone else.
That's not the issue.
Since it's obvious that you don't accept my argument, it's pointless
discussing it further; there's nothing I can realistically do at this
end to resolve the issue and still remain part of this community.
I see no point in further discussion of this issue if such bigotry is
going to continue; any further responses on this topic will not receive
any replies from me.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Tue, Jun 05, 2007 at 04:18:47PM +0100, Russell King wrote:
> > If you are unwilling to fix the problem and work within existing
> > community email standards, I think it would be fair to ask vger
> > postmaster to start excising Mail-Followup-To headers.
>
> Well, that will leave me with _no_ _choice_ but to arrange for the
> SMTP MAIL FROM from others to receive a 550 error code to remove
> the problem. Is that really what you'd like me to do?
>
> > You are NOT more important that everyone else.
>
> That's not the issue.
>
> Since it's obvious that you don't accept my argument, it's pointless
> discussing it further; there's nothing I can realistically do at this
> end to resolve the issue and still remain part of this community.
>
> I see no point in further discussion of this issue if such bigotry is
> going to continue; any further responses on this topic will not receive
> any replies from me.
Oh sod it, I'm unsubscribing from LKML. Jeff, hope your happy.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Tue, Jun 05, 2007 at 04:18:47PM +0100, Russell King wrote:
> Meanwhile you decide that you have a right over _MY_ personal preferences.
> It's the same argument I'm afraid, just a different point of view. If
> _you_ do not wish to abide by the header then turn off that feature in
> your mailer. That's _your_ preference and one which _you_ can set.
That clearly doesn't fix the MUAs of everyone else, which has the
stated behavior: if Mail-Followup-To is present, stuff everyone into
the To header. And who originates this header?
It's a broken behavior overall, and in a sane world, it would excise you
from the To: header, and leave everyone else on CC as per normal MUA
standards. But it's not a sane world :)
As such, it is -your- responsibility to make sure breakage does not
occur, since the breakage is originated from -your- setup.
Jeff
On Tue, Jun 05, 2007 at 11:41:57AM -0400, Jeff Garzik wrote:
> On Tue, Jun 05, 2007 at 04:18:47PM +0100, Russell King wrote:
> > Meanwhile you decide that you have a right over _MY_ personal preferences.
> > It's the same argument I'm afraid, just a different point of view. If
> > _you_ do not wish to abide by the header then turn off that feature in
> > your mailer. That's _your_ preference and one which _you_ can set.
>
> That clearly doesn't fix the MUAs of everyone else, which has the
> stated behavior: if Mail-Followup-To is present, stuff everyone into
> the To header. And who originates this header?
>
> It's a broken behavior overall, and in a sane world, it would excise you
> from the To: header, and leave everyone else on CC as per normal MUA
> standards. But it's not a sane world :)
>
> As such, it is -your- responsibility to make sure breakage does not
> occur, since the breakage is originated from -your- setup.
There's no point discussing this any further - I've unsubscribed from
linux-kernel. Problem solved.
| From: [email protected]
| Subject: Majordomo results: unsubscribe
| Reply-To: [email protected]
| Date: Tue, 5 Jun 2007 11:22:06 -0400
|
| --
|
| >>>> unsubscribe linux-kernel
| Succeeded.
| >>>> end
| END OF COMMANDS
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
> If you don't have DMA capabilities, does libata still need ->pad and
> ->pad_dma set?
It shouldn't - nor the prd. You don't need to use the default
ata_port_start in this case. I've just added ata_sff_port_start to my
tree which figures out which to allocate for SFF devices.
On Tue, Jun 05, 2007 at 04:50:56PM +0100, Alan Cox wrote:
> > If you don't have DMA capabilities, does libata still need ->pad and
> > ->pad_dma set?
>
> It shouldn't - nor the prd. You don't need to use the default
> ata_port_start in this case. I've just added ata_sff_port_start to my
> tree which figures out which to allocate for SFF devices.
I had already sorted out the PRD, but I couldn't convince myself that
the pad stuff wasn't used, so for pata_icside I had:
static int pata_icside_port_start(struct ata_port *ap)
{
/* No PRD to alloc */
return ata_pad_alloc(ap, ap->dev);
}
Therefore, I can just arrange for this to do nothing and just return
zero. A similar fix for pata_platform should probably also be in order
as well.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
From: Russell King <[email protected]>
Date: Tue, 5 Jun 2007 15:59:46 +0100
> It's the fact that I _am_ CC'd on replies, so I get one message from LKML
> one from the original poster, maybe one via another mailing list if it's
> also copied there. Add that in to the mix of all the other mail hitting
> my MTA and the probability for the machine to exhaust it's limited VM is
> very high.
Russell, be serious.
I've been doing this for more than 10 years, using my measly
workstation as my mail server for everything, and being VGER
postmaster on top of it all, and I never have this problem and
I think I get tons more email than you ever will.
Just becuase you want to run your mail server on a machine with very
limited resources, doesn't make it reasonable to hijack the headers on
everyone else like you do.
From: Jeff Garzik <[email protected]>
Date: Tue, 5 Jun 2007 11:11:04 -0400
> On Tue, Jun 05, 2007 at 03:59:46PM +0100, Russell King wrote:
> > Give me a way to stop people CC'ing me on replies and I'll happily remove
> > the header. Unfortunately there isn't, so I can't.
>
> So by fiat, you decide that gives you the right to override OTHER
> PEOPLE'S personal preferences? Why are you so much more important
> to a thread than everyone else?
>
> If you are unwilling to fix the problem and work within existing
> community email standards, I think it would be fair to ask vger
> postmaster to start excising Mail-Followup-To headers.
>
> You are NOT more important that everyone else.
>
> Stop hijacking EVERYONE ELSE's email preferences.
I totally agree, Russel you are being totally unreasonable.
A lot of us get a TON more email than you ever will and we do not crap
on email threads the way you do.
From: Russell King <[email protected]>
Date: Tue, 5 Jun 2007 16:18:47 +0100
> On Tue, Jun 05, 2007 at 11:11:04AM -0400, Jeff Garzik wrote:
> > You are NOT more important that everyone else.
>
> That's not the issue.
Yes it is, you're imposing your lousy solution to your
problems on other people.
Meanwhile those of us who get several orders of magnitude more email
than you do absolutely do not feel so compelled to crap on other
people's email experience like you do.
From: Russell King <[email protected]>
Date: Tue, 5 Jun 2007 16:21:33 +0100
> Oh sod it, I'm unsubscribing from LKML. Jeff, hope your happy.
What an adult way for you to handle this.
On 06/05/2007 03:24 PM, David Miller wrote:
>
> I totally agree, Russel you are being totally unreasonable.
>
^^
Uh-oh.
On Tue, Jun 05, 2007 at 12:23:35PM -0700, David Miller wrote:
> From: Russell King <[email protected]>
> Date: Tue, 5 Jun 2007 15:59:46 +0100
>
> > It's the fact that I _am_ CC'd on replies, so I get one message from LKML
> > one from the original poster, maybe one via another mailing list if it's
> > also copied there. Add that in to the mix of all the other mail hitting
> > my MTA and the probability for the machine to exhaust it's limited VM is
> > very high.
>
> Russell, be serious.
I am serious, and to show how serious I am I've unsubscribed from LKML.
> Just becuase you want to run your mail server on a machine with very
> limited resources, doesn't make it reasonable to hijack the headers on
> everyone else like you do.
I run on limited resources with limited physical space, I make the
best of what I have. I'm sorry, I don't feel that given the restrictions
that bigots on LKML have imposed that I can continue being on this
mailing list.
So I've gone. Live with it.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Tue, Jun 05, 2007 at 12:27:45PM -0700, David Miller wrote:
> From: Russell King <[email protected]>
> Date: Tue, 5 Jun 2007 16:21:33 +0100
>
> > Oh sod it, I'm unsubscribing from LKML. Jeff, hope your happy.
>
> What an adult way for you to handle this.
Indeed; it's obvious that you're not listening to reason, so I won't
waste my time and everyone elses trying to get through to people who
just aren't listening.
I've gone. Congratulations.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Tue, Jun 05, 2007 at 10:25:23PM +0100, Russell King wrote:
> On Tue, Jun 05, 2007 at 12:27:45PM -0700, David Miller wrote:
> > From: Russell King <[email protected]>
> > Date: Tue, 5 Jun 2007 16:21:33 +0100
> >
> > > Oh sod it, I'm unsubscribing from LKML. Jeff, hope your happy.
> >
> > What an adult way for you to handle this.
>
> Indeed; it's obvious that you're not listening to reason, so I won't
> waste my time and everyone elses trying to get through to people who
> just aren't listening.
>
> I've gone. Congratulations.
There is one final point on this which I wish to make, in case anyone
has decided that this is caused by some recent change at my end.
I've been adding this header to all my messages for about the last seven
years. It's only *just* become a problem because someone here made a
decision that it was a problem.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Tue, Jun 05, 2007 at 10:38:15PM +0100, Russell King wrote:
> There is one final point on this which I wish to make, in case anyone
> has decided that this is caused by some recent change at my end.
>
> I've been adding this header to all my messages for about the last seven
> years. It's only *just* become a problem because someone here made a
> decision that it was a problem.
Search LKML for other mentions of Mail-Followup-To; this is far from the
first time it's been brought up.
I'm probably one of the few who actually investigated why their MUA was
suddenly doing weird, RFC-unfriendly things to the To/CC headers,
tracking it down the Mail-Followup-To header.
Jeff
On Tue, Jun 05, 2007 at 05:48:30PM -0400, Jeff Garzik wrote:
> On Tue, Jun 05, 2007 at 10:38:15PM +0100, Russell King wrote:
> > There is one final point on this which I wish to make, in case anyone
> > has decided that this is caused by some recent change at my end.
> >
> > I've been adding this header to all my messages for about the last seven
> > years. It's only *just* become a problem because someone here made a
> > decision that it was a problem.
>
> Search LKML for other mentions of Mail-Followup-To; this is far from the
> first time it's been brought up.
>
> I'm probably one of the few who actually investigated why their MUA was
> suddenly doing weird, RFC-unfriendly things to the To/CC headers,
> tracking it down the Mail-Followup-To header.
And rather than configuring your MUA to ignore the header...
You're using mutt, mutt can be configured so.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Tue, Jun 05, 2007 at 11:03:45PM +0100, Russell King wrote:
> On Tue, Jun 05, 2007 at 05:48:30PM -0400, Jeff Garzik wrote:
> > On Tue, Jun 05, 2007 at 10:38:15PM +0100, Russell King wrote:
> > > There is one final point on this which I wish to make, in case anyone
> > > has decided that this is caused by some recent change at my end.
> > >
> > > I've been adding this header to all my messages for about the last seven
> > > years. It's only *just* become a problem because someone here made a
> > > decision that it was a problem.
> >
> > Search LKML for other mentions of Mail-Followup-To; this is far from the
> > first time it's been brought up.
> >
> > I'm probably one of the few who actually investigated why their MUA was
> > suddenly doing weird, RFC-unfriendly things to the To/CC headers,
> > tracking it down the Mail-Followup-To header.
>
> And rather than configuring your MUA to ignore the header...
> You're using mutt, mutt can be configured so.
So, you are seriously proposing that EVERYONE reconfigure their MUA,
because you are sending out bad headers?
Don't you think that is an unscalable solution, and an imposition?
Jeff
On Tue, 05 Jun 2007 18:16:25 EDT, Jeff Garzik said:
> On Tue, Jun 05, 2007 at 11:03:45PM +0100, Russell King wrote:
> > And rather than configuring your MUA to ignore the header...
>
> > You're using mutt, mutt can be configured so.
>
> So, you are seriously proposing that EVERYONE reconfigure their MUA,
> because you are sending out bad headers?
>
> Don't you think that is an unscalable solution, and an imposition?
Not only is it unscalable, it almost by definition is anti-social. The only
times I've actually seen one in the wild, it's because some subscriber to a
mailing list wishes to subvert the list's culture in a manner worse than
a Reply-To: header. I considered adding support for Mail-Followup-To: to
the exmh MUA, but decided against it, because it would basically mean that
every time I got one, I'd have to curse and moan and put the To: and cc: back
the way everybody *else* on the list wanted those to headers to behave. Kind
of hard to motivate myself to write Tk/Tcl code that will just mean a *worse*
user experience for myself...