Re: [PATCH] of/lib: Export fdt routines to modules

Re: [PATCH] of/lib: Export fdt routines to modules

[Guenter Roeck]

On 10/17/2013 04:51 PM, Michael Bohan wrote:
> On Wed, Oct 16, 2013 at 09:54:27PM -0700, Guenter Roeck wrote:
>> On 10/16/2013 05:27 PM, Michael Bohan wrote:
>>> My motivation is actually to use the fdt format as a firmware.
>>> I have a requirement to express driver metadata that's loadable
>> >from the filesystem. This data is not reasonable to place in the
>>> system Device Tree, since it's application specific and does not
>>> actually describe hardware. The fact that the format chosen is
>>> 'flattened device tree' is merely just a coincidence.
>>>
>> Still, what prevents you from unflattening it and just using the
>> normal device tree functions as David suggested ?
>
> I'm assuming you're suggesting to use of_fdt_unflatten_tree()?

Yes, that was the idea.

> That's an interesting thought. I was planning to scan the fdt
> only once and populate my own structures, but I suppose I could
> use the of_* APIs equivalently.
>
> It seems there are some problems though.  of_fdt_unflatten_tree()
> does not return errors, and so for the purposes of my driver it
> would not be sufficient to detect an invalid firmware image.
>
It does so, at least partially. If there is an error, it won't set
the nodes pointer. Granted, that is not perfect, but it is at least
a start. Ultimately, I considered it 'good enough' for my purpose
(for devicetree overlays - see [1] below), as any missing mandatory
properties or nodes are detected later when trying to actually read
the properties. In my case, I also have a couple of validation
properties to ensure that the overlay is acceptable (specifically
I use 'compatible' and 'assembly-ids', but that is really a detail).

> Would people entertain changing this API
> (and implicitly __unflatten_device_tree) to return errors? I'm
> guessing the reason it's coded that way is because the normal
> usecase is 'system boot', at which time errors aren't that
> meaningful.
>
> Also, there's no way to free the memory that was allocated from
> the unflatten process. May I add one?
>

The patchset submitted by Pantelis Antoniou to add support for
devicetree overlays adds this and other related functionality.
See [1], specifically the patch titled "OF: Introduce utility
helper functions". Not sure where that is going, though.
It may need some cleanup to be accepted upstream.
Copying Pantelis for comments.

I also updated the devicetree discussion list address to get comments
from the experts.

Thanks,
Guenter

[1] https://lkml.org/lkml/2013/1/4/276

Re: [PATCH] of/lib: Export fdt routines to modules

[Michael Bohan]

On Thu, Oct 17, 2013 at 05:44:07PM -0700, Guenter Roeck wrote:
> On 10/17/2013 04:51 PM, Michael Bohan wrote:
> >On Wed, Oct 16, 2013 at 09:54:27PM -0700, Guenter Roeck wrote:
> >>Still, what prevents you from unflattening it and just using the
> >>normal device tree functions as David suggested ?
> >
> >I'm assuming you're suggesting to use of_fdt_unflatten_tree()?
> 
> Yes, that was the idea.
> 
> >That's an interesting thought. I was planning to scan the fdt
> >only once and populate my own structures, but I suppose I could
> >use the of_* APIs equivalently.
> >
> >It seems there are some problems though.  of_fdt_unflatten_tree()
> >does not return errors, and so for the purposes of my driver it
> >would not be sufficient to detect an invalid firmware image.
> >
> It does so, at least partially. If there is an error, it won't set
> the nodes pointer. Granted, that is not perfect, but it is at least
> a start. Ultimately, I considered it 'good enough' for my purpose
> (for devicetree overlays - see [1] below), as any missing mandatory
> properties or nodes are detected later when trying to actually read
> the properties. In my case, I also have a couple of validation
> properties to ensure that the overlay is acceptable (specifically
> I use 'compatible' and 'assembly-ids', but that is really a detail).

That's certainly better than nothing, but I think it would be
useful to make a distinction between a malformed fdt and a fdt
that's simply missing the right information. Without error
codes, I think we lose this aspect.

> >Would people entertain changing this API
> >(and implicitly __unflatten_device_tree) to return errors? I'm
> >guessing the reason it's coded that way is because the normal
> >usecase is 'system boot', at which time errors aren't that
> >meaningful.
> >
> >Also, there's no way to free the memory that was allocated from
> >the unflatten process. May I add one?
> >
> 
> The patchset submitted by Pantelis Antoniou to add support for
> devicetree overlays adds this and other related functionality.
> See [1], specifically the patch titled "OF: Introduce utility
> helper functions". Not sure where that is going, though.
> It may need some cleanup to be accepted upstream.
> Copying Pantelis for comments.
> Guenter
> 
> [1] https://lkml.org/lkml/2013/1/4/276

Thanks. So it seems that Pantelis's __of_free_tree() is what I'm
looking for.

Mike

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

Re: [PATCH] of/lib: Export fdt routines to modules

[Pantelis Antoniou]

Hi Michael,

On Oct 18, 2013, at 5:54 AM, Michael Bohan wrote:

> On Thu, Oct 17, 2013 at 05:44:07PM -0700, Guenter Roeck wrote:
>> On 10/17/2013 04:51 PM, Michael Bohan wrote:
>>> On Wed, Oct 16, 2013 at 09:54:27PM -0700, Guenter Roeck wrote:
>>>> Still, what prevents you from unflattening it and just using the
>>>> normal device tree functions as David suggested ?
>>> 
>>> I'm assuming you're suggesting to use of_fdt_unflatten_tree()?
>> 
>> Yes, that was the idea.
>> 
>>> That's an interesting thought. I was planning to scan the fdt
>>> only once and populate my own structures, but I suppose I could
>>> use the of_* APIs equivalently.
>>> 
>>> It seems there are some problems though.  of_fdt_unflatten_tree()
>>> does not return errors, and so for the purposes of my driver it
>>> would not be sufficient to detect an invalid firmware image.
>>> 
>> It does so, at least partially. If there is an error, it won't set
>> the nodes pointer. Granted, that is not perfect, but it is at least
>> a start. Ultimately, I considered it 'good enough' for my purpose
>> (for devicetree overlays - see [1] below), as any missing mandatory
>> properties or nodes are detected later when trying to actually read
>> the properties. In my case, I also have a couple of validation
>> properties to ensure that the overlay is acceptable (specifically
>> I use 'compatible' and 'assembly-ids', but that is really a detail).
> 
> That's certainly better than nothing, but I think it would be
> useful to make a distinction between a malformed fdt and a fdt
> that's simply missing the right information. Without error
> codes, I think we lose this aspect.
> 
>>> Would people entertain changing this API
>>> (and implicitly __unflatten_device_tree) to return errors? I'm
>>> guessing the reason it's coded that way is because the normal
>>> usecase is 'system boot', at which time errors aren't that
>>> meaningful.
>>> 
>>> Also, there's no way to free the memory that was allocated from
>>> the unflatten process. May I add one?
>>> 
>> 
>> The patchset submitted by Pantelis Antoniou to add support for
>> devicetree overlays adds this and other related functionality.
>> See [1], specifically the patch titled "OF: Introduce utility
>> helper functions". Not sure where that is going, though.
>> It may need some cleanup to be accepted upstream.
>> Copying Pantelis for comments.
>> Guenter
>> 
>> [1] https://lkml.org/lkml/2013/1/4/276
> 
> Thanks. So it seems that Pantelis's __of_free_tree() is what I'm
> looking for.
> 

I guess it's time for another try to getting it in?

DT maintainers, which one of you will want to review?

> Mike
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation

Regards

-- Pantelis

Re: [PATCH] of/lib: Export fdt routines to modules

[Rob Herring]

On 10/18/2013 08:28 AM, Pantelis Antoniou wrote:
> Hi Michael,
> 
> On Oct 18, 2013, at 5:54 AM, Michael Bohan wrote:
> 
>> On Thu, Oct 17, 2013 at 05:44:07PM -0700, Guenter Roeck wrote:
>>> On 10/17/2013 04:51 PM, Michael Bohan wrote:
>>>> On Wed, Oct 16, 2013 at 09:54:27PM -0700, Guenter Roeck wrote:
>>>>> Still, what prevents you from unflattening it and just using the
>>>>> normal device tree functions as David suggested ?
>>>>
>>>> I'm assuming you're suggesting to use of_fdt_unflatten_tree()?
>>>
>>> Yes, that was the idea.
>>>
>>>> That's an interesting thought. I was planning to scan the fdt
>>>> only once and populate my own structures, but I suppose I could
>>>> use the of_* APIs equivalently.
>>>>
>>>> It seems there are some problems though.  of_fdt_unflatten_tree()
>>>> does not return errors, and so for the purposes of my driver it
>>>> would not be sufficient to detect an invalid firmware image.
>>>>
>>> It does so, at least partially. If there is an error, it won't set
>>> the nodes pointer. Granted, that is not perfect, but it is at least
>>> a start. Ultimately, I considered it 'good enough' for my purpose
>>> (for devicetree overlays - see [1] below), as any missing mandatory
>>> properties or nodes are detected later when trying to actually read
>>> the properties. In my case, I also have a couple of validation
>>> properties to ensure that the overlay is acceptable (specifically
>>> I use 'compatible' and 'assembly-ids', but that is really a detail).
>>
>> That's certainly better than nothing, but I think it would be
>> useful to make a distinction between a malformed fdt and a fdt
>> that's simply missing the right information. Without error
>> codes, I think we lose this aspect.
>>
>>>> Would people entertain changing this API
>>>> (and implicitly __unflatten_device_tree) to return errors? I'm
>>>> guessing the reason it's coded that way is because the normal
>>>> usecase is 'system boot', at which time errors aren't that
>>>> meaningful.
>>>>
>>>> Also, there's no way to free the memory that was allocated from
>>>> the unflatten process. May I add one?
>>>>
>>>
>>> The patchset submitted by Pantelis Antoniou to add support for
>>> devicetree overlays adds this and other related functionality.
>>> See [1], specifically the patch titled "OF: Introduce utility
>>> helper functions". Not sure where that is going, though.
>>> It may need some cleanup to be accepted upstream.
>>> Copying Pantelis for comments.
>>> Guenter
>>>
>>> [1] https://lkml.org/lkml/2013/1/4/276
>>
>> Thanks. So it seems that Pantelis's __of_free_tree() is what I'm
>> looking for.
>>
> 
> I guess it's time for another try to getting it in?
> 
> DT maintainers, which one of you will want to review?

This falls in Grant's and my plate since we are talking kernel DT
support code rather than bindings. Unflattening is definitely the right
direction to go here.

Rob

Re: [PATCH] of/lib: Export fdt routines to modules

[Guenter Roeck]

On Fri, Oct 18, 2013 at 10:57:24AM -0500, Rob Herring wrote:
> On 10/18/2013 08:28 AM, Pantelis Antoniou wrote:
> > Hi Michael,
> > 
> > On Oct 18, 2013, at 5:54 AM, Michael Bohan wrote:
> > 
> >> On Thu, Oct 17, 2013 at 05:44:07PM -0700, Guenter Roeck wrote:
> >>> On 10/17/2013 04:51 PM, Michael Bohan wrote:
> >>>> On Wed, Oct 16, 2013 at 09:54:27PM -0700, Guenter Roeck wrote:
> >>>>> Still, what prevents you from unflattening it and just using the
> >>>>> normal device tree functions as David suggested ?
> >>>>
> >>>> I'm assuming you're suggesting to use of_fdt_unflatten_tree()?
> >>>
> >>> Yes, that was the idea.
> >>>
> >>>> That's an interesting thought. I was planning to scan the fdt
> >>>> only once and populate my own structures, but I suppose I could
> >>>> use the of_* APIs equivalently.
> >>>>
> >>>> It seems there are some problems though.  of_fdt_unflatten_tree()
> >>>> does not return errors, and so for the purposes of my driver it
> >>>> would not be sufficient to detect an invalid firmware image.
> >>>>
> >>> It does so, at least partially. If there is an error, it won't set
> >>> the nodes pointer. Granted, that is not perfect, but it is at least
> >>> a start. Ultimately, I considered it 'good enough' for my purpose
> >>> (for devicetree overlays - see [1] below), as any missing mandatory
> >>> properties or nodes are detected later when trying to actually read
> >>> the properties. In my case, I also have a couple of validation
> >>> properties to ensure that the overlay is acceptable (specifically
> >>> I use 'compatible' and 'assembly-ids', but that is really a detail).
> >>
> >> That's certainly better than nothing, but I think it would be
> >> useful to make a distinction between a malformed fdt and a fdt
> >> that's simply missing the right information. Without error
> >> codes, I think we lose this aspect.
> >>
> >>>> Would people entertain changing this API
> >>>> (and implicitly __unflatten_device_tree) to return errors? I'm
> >>>> guessing the reason it's coded that way is because the normal
> >>>> usecase is 'system boot', at which time errors aren't that
> >>>> meaningful.
> >>>>
> >>>> Also, there's no way to free the memory that was allocated from
> >>>> the unflatten process. May I add one?
> >>>>
> >>>
> >>> The patchset submitted by Pantelis Antoniou to add support for
> >>> devicetree overlays adds this and other related functionality.
> >>> See [1], specifically the patch titled "OF: Introduce utility
> >>> helper functions". Not sure where that is going, though.
> >>> It may need some cleanup to be accepted upstream.
> >>> Copying Pantelis for comments.
> >>> Guenter
> >>>
> >>> [1] https://lkml.org/lkml/2013/1/4/276
> >>
> >> Thanks. So it seems that Pantelis's __of_free_tree() is what I'm
> >> looking for.
> >>
> > 
> > I guess it's time for another try to getting it in?
> > 
> > DT maintainers, which one of you will want to review?
> 
> This falls in Grant's and my plate since we are talking kernel DT
> support code rather than bindings. Unflattening is definitely the right
> direction to go here.
> 
I think Pantelis may have been asking about his devicetree overlay
support patch series.

Pantelis, did you have time to address the review comments you got earlier ?

Thanks,
Guenter

Re: [PATCH] of/lib: Export fdt routines to modules

[David Daney]

On 10/18/2013 08:57 AM, Rob Herring wrote:
[...]
>
> Unflattening is definitely the right
> direction to go here.
>

I wonder if that is really true.

The device tree in question is very short lived, and used to control the 
configuration of some hardware device when loading the driver.

The use of it is completely contained within a single driver (at least 
that is my understanding), it is not information that needs to be shared 
system wide.

Given that it is a driver implementation issue, rather than making 
things work nicely system wide, I don't think it really matters what is 
done.

It may be that the overhead of unflattening the tree and then freeing 
it, is much greater than just extracting a few things from the FDT.

That said, I don't really have a preference for what is done.  My 
original questions were targeted at understanding this particular use case.

David Daney

Re: [PATCH] of/lib: Export fdt routines to modules

[Michael Bohan]

On Fri, Oct 18, 2013 at 09:30:32AM -0700, David Daney wrote:
> On 10/18/2013 08:57 AM, Rob Herring wrote:
> [...]
> >
> >Unflattening is definitely the right
> >direction to go here.
> >
> 
> I wonder if that is really true.
> 
> The device tree in question is very short lived, and used to control
> the configuration of some hardware device when loading the driver.
> 
> The use of it is completely contained within a single driver (at
> least that is my understanding), it is not information that needs to
> be shared system wide.

That's correct.

> Given that it is a driver implementation issue, rather than making
> things work nicely system wide, I don't think it really matters what
> is done.
> 
> It may be that the overhead of unflattening the tree and then
> freeing it, is much greater than just extracting a few things from
> the FDT.

Yes, this was my original thought as well. On the other hand,
having libfdt in the kernel does add a little extra bloat, and so
it seems a tradeoff from one-time runtime overhead to footprint.

> That said, I don't really have a preference for what is done.  My
> original questions were targeted at understanding this particular
> use case.

My preference is probably straight libfdt calls, but if others
think that unpacking is a better solution, I'm able to go that
route as well. My only concern there is that we provide a means
to detect invalid dtb image (ex. handle error codes) and also
free the device_node allocations once the device is released.

Thanks,
Mike

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/lib: Export fdt routines to modules

[Rob Herring]

On 10/18/2013 02:32 PM, Michael Bohan wrote:
> On Fri, Oct 18, 2013 at 09:30:32AM -0700, David Daney wrote:
>> On 10/18/2013 08:57 AM, Rob Herring wrote:
>> [...]
>>>
>>> Unflattening is definitely the right
>>> direction to go here.
>>>
>>
>> I wonder if that is really true.
>>
>> The device tree in question is very short lived, and used to control
>> the configuration of some hardware device when loading the driver.
>>
>> The use of it is completely contained within a single driver (at
>> least that is my understanding), it is not information that needs to
>> be shared system wide.
> 
> That's correct.
> 
>> Given that it is a driver implementation issue, rather than making
>> things work nicely system wide, I don't think it really matters what
>> is done.
>>
>> It may be that the overhead of unflattening the tree and then
>> freeing it, is much greater than just extracting a few things from
>> the FDT.
> 
> Yes, this was my original thought as well. On the other hand,
> having libfdt in the kernel does add a little extra bloat, and so
> it seems a tradeoff from one-time runtime overhead to footprint.
> 
>> That said, I don't really have a preference for what is done.  My
>> original questions were targeted at understanding this particular
>> use case.
> 
> My preference is probably straight libfdt calls, but if others
> think that unpacking is a better solution, I'm able to go that
> route as well. My only concern there is that we provide a means
> to detect invalid dtb image (ex. handle error codes) and also
> free the device_node allocations once the device is released.

I think we need to understand what you are putting in the DT first.

Given there are other desired uses like overlays which need to add the
necessary loading and unflattening support, a common solution is likely
more desirable.

Rob

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/lib: Export fdt routines to modules

[Michael Bohan]

On Fri, Oct 18, 2013 at 04:20:09PM -0500, Rob Herring wrote:
> On 10/18/2013 02:32 PM, Michael Bohan wrote:
> > My preference is probably straight libfdt calls, but if others
> > think that unpacking is a better solution, I'm able to go that
> > route as well. My only concern there is that we provide a means
> > to detect invalid dtb image (ex. handle error codes) and also
> > free the device_node allocations once the device is released.
> 
> I think we need to understand what you are putting in the DT first.

That's understandable. Please see my response to Mark.

> Given there are other desired uses like overlays which need to add the
> necessary loading and unflattening support, a common solution is likely
> more desirable.

But by convention, would overlays allow for 'application
specific' data, or are they expected to meet the more rigid
requirements of a real Device Tree?

Thanks,
Mike

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

Re: [PATCH] of/lib: Export fdt routines to modules

[Guenter Roeck]

On 10/18/2013 06:49 PM, Michael Bohan wrote:
> On Fri, Oct 18, 2013 at 04:20:09PM -0500, Rob Herring wrote:
>> On 10/18/2013 02:32 PM, Michael Bohan wrote:
>>> My preference is probably straight libfdt calls, but if others
>>> think that unpacking is a better solution, I'm able to go that
>>> route as well. My only concern there is that we provide a means
>>> to detect invalid dtb image (ex. handle error codes) and also
>>> free the device_node allocations once the device is released.
>>
>> I think we need to understand what you are putting in the DT first.
>
> That's understandable. Please see my response to Mark.
>
>> Given there are other desired uses like overlays which need to add the
>> necessary loading and unflattening support, a common solution is likely
>> more desirable.
>
> But by convention, would overlays allow for 'application
> specific' data, or are they expected to meet the more rigid
> requirements of a real Device Tree?
>

Not that I am the authority on it, but the idea is that devicetree overlays
will be merged with the existing devicetree, which implies that the same
requirements would apply.

However, you would not really use overlays. You would use the devicetree
infrastructure to create a logically separate instance of a devicetree
to dynamically configure your driver (which I think is an ingenious idea).
I don't think the same rules would or should apply there.

Guenter

Re: [PATCH] of/lib: Export fdt routines to modules

[Mark Rutland]

Hi all,

Guenter, thanks for adding devicetree to Cc.

On Fri, Oct 18, 2013 at 01:44:07AM +0100, Guenter Roeck wrote:
> On 10/17/2013 04:51 PM, Michael Bohan wrote:
> > On Wed, Oct 16, 2013 at 09:54:27PM -0700, Guenter Roeck wrote:
> >> On 10/16/2013 05:27 PM, Michael Bohan wrote:
> >>> My motivation is actually to use the fdt format as a firmware.
> >>> I have a requirement to express driver metadata that's loadable
> >> >from the filesystem. This data is not reasonable to place in the
> >>> system Device Tree, since it's application specific and does not
> >>> actually describe hardware. The fact that the format chosen is
> >>> 'flattened device tree' is merely just a coincidence.

Michael, could you elaborate on using the fdt format "as a firmware" and
what driver metadata you need to be loadable from the filesystem?

How are you intending to pass the DT to the kernel from userspace?

Given that you mention this is application-specific configuration, why
is using sysfs attributes or some other sort of filesystem interaction
not appropriate?

Thanks,
Mark.

Re: [PATCH] of/lib: Export fdt routines to modules

[Michael Bohan]

On Fri, Oct 18, 2013 at 07:38:04PM +0100, Mark Rutland wrote:

Hi Mark,

> On Fri, Oct 18, 2013 at 01:44:07AM +0100, Guenter Roeck wrote:
> > On 10/17/2013 04:51 PM, Michael Bohan wrote:
> > > On Wed, Oct 16, 2013 at 09:54:27PM -0700, Guenter Roeck wrote:
> > >> On 10/16/2013 05:27 PM, Michael Bohan wrote:
> > >>> My motivation is actually to use the fdt format as a firmware.
> > >>> I have a requirement to express driver metadata that's loadable
> > >> >from the filesystem. This data is not reasonable to place in the
> > >>> system Device Tree, since it's application specific and does not
> > >>> actually describe hardware. The fact that the format chosen is
> > >>> 'flattened device tree' is merely just a coincidence.
> 
> Michael, could you elaborate on using the fdt format "as a firmware" and
> what driver metadata you need to be loadable from the filesystem?

We have a hardware device in which of its internal register state
is reconfigured for each application that uses it. And we may
need to quickly swap between applications many times within the
life of the system, so all of the data needs to be preloaded
ahead of the time. There's a lot of data that needs to be updated
in one-shot, and unfortunately there's really no great way to
abstract much of this information.

This metadata file is generated by a tool and lives on the
filesystem, and exists mainly so that each higher level
application driver doesn't need to change its code when such
parameters change. We also want it to be human-readable so that
people can view it, and possibly even tweak it by hand. As
mentioned, most of the data represent actual hardware
configurations, but some others describe per application software
implementation details.

> How are you intending to pass the DT to the kernel from userspace?

request_firmware()

> Given that you mention this is application-specific configuration, why
> is using sysfs attributes or some other sort of filesystem interaction
> not appropriate?

Sysfs is another option, but the major problem is that the driver
doesn't know the full list of applications until it reads the
firmware file. So if we went the sysfs route, it seems we'd need
to form some sort of 'virtual device' hierarchy so that the sysfs
files map 1:1 with each application. That is, read the metadata
file, and for each 'application node', instruct the driver to
create a virtual device for that application node, exposing sysfs
files that can hold its data. To me this seems a bit excessive
and complicated.

Another option would to have a flat sysfs representation and
have the write of one special file create an internal application
database entry for that configuration.

The point is, we can't proceed with normal operation until we
have the total list of applications and their respective
properties registered in memory.

But writing all the sysfs files could be expensive. There would
be complicated tables of different formats that would be
consuming to run through all the different possible entries.

To be honest, I mostly just thought the fdt would be a cool
implementation. It handles all of our requirements, while reusing
infrastructure within and external to the kernel.

Thanks,
Mike

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html