Discussion about the development of the cross-platform user space library for accessing usb devices.

Christoph Sander | 15 Aug 2012 16:30

Picon

Picon

same productID + VendorID für application and bootloader

Hi, 

When i use the same productID + vendorID für my application and the bootloader, the libusb does not
recognize when i switch from application to bootloader or the other way. The libusb still responds with
the old descriptor. When i get a new context, i get the correct descriptor. Is there a way to update the list
without generating a new context? Or is there something else i do wrong?

Kind Regards
Chris         

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusb-devel mailing list
libusb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Peter Stuge | 15 Aug 2012 18:20

Picon

Re: same productID + VendorID für application and bootloader

Christoph Sander wrote:
> When i use the same productID + vendorID für my application and the
> bootloader

Don't do that.

> the libusb does not recognize when i switch from application to
> bootloader or the other way.

Use different pids and disconnect from the bus.

> The libusb still responds with the old descriptor. When i get a new
> context, i get the correct descriptor.
> Is there a way to update the list without generating a new context?

Unref and free the libusb_device * and call libusb_get_device_list()
again - that should not return cached data.

> Or is there something else i do wrong?

Using one pid for two different sets of descriptors is wrong.

It's not wrong in the spec sense, but it's wrong in the practical
sense. It just works poorly. If you need more pids for an open source
project, ask openmoko. They will be happy to give you some.

//Peter

------------------------------------------------------------------------------
Live Security Virtual Conference

(Continue reading)

Xiaofan Chen | 16 Aug 2012 04:39

Picon

Re: same productID + VendorID für application and bootloader

On Thu, Aug 16, 2012 at 12:20 AM, Peter Stuge <peter <at> stuge.se> wrote:
> Christoph Sander wrote:
>> The libusb still responds with the old descriptor. When i get a new
>> context, i get the correct descriptor.
>> Is there a way to update the list without generating a new context?
>
> Unref and free the libusb_device * and call libusb_get_device_list()
> again - that should not return cached data.
>
>
>> Or is there something else i do wrong?
>
> Using one pid for two different sets of descriptors is wrong.
>
> It's not wrong in the spec sense, but it's wrong in the practical
> sense. It just works poorly. If you need more pids for an open source
> project, ask openmoko. They will be happy to give you some.
>

Unfortunately that is what many vendors do. Many FTDI based
device use the same VID/PID for full speed and high speed
version. One reason is related to the fact that the device
vendor only gets one or limited number of free PIDs from the
VID holders (chip vendors). The other thing is that USBIF
does not allow VID holders to sell individual PIDs to
small USB device vendors. Yet another reason can
be related to WHQL, vendors may get WHQL once
for one particular VID/PID combination and do not want
to pay money again for another similar device.

(Continue reading)

Alan Stern | 16 Aug 2012 14:09

Picon

Re: Re: same productID + VendorID für application and bootloader

On Thu, 16 Aug 2012, Xiaofan Chen wrote:

> > Using one pid for two different sets of descriptors is wrong.
> >
> > It's not wrong in the spec sense, but it's wrong in the practical
> > sense. It just works poorly. If you need more pids for an open source
> > project, ask openmoko. They will be happy to give you some.
> >
> 
> Unfortunately that is what many vendors do. Many FTDI based
> device use the same VID/PID for full speed and high speed
> version. One reason is related to the fact that the device
> vendor only gets one or limited number of free PIDs from the
> VID holders (chip vendors). The other thing is that USBIF
> does not allow VID holders to sell individual PIDs to
> small USB device vendors. Yet another reason can
> be related to WHQL, vendors may get WHQL once
> for one particular VID/PID combination and do not want
> to pay money again for another similar device.

You can always change the bcdDevice value.  That ought to be just as 
good as changing the idVendor or idProduct.

Alan Stern

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware

(Continue reading)

Christoph Sander | 16 Aug 2012 15:19

Picon

Picon

Re: Re: same productID + VendorID für application and bootloader

Thx for the help, but i still have open questions i hope u can help me with

> It can make to work if the device detaches and then re-attaches
> to the bus (reset or soft-detach) and the PC application search
> for new device again when switching from bootloader to the main
> firmware.
> 
> -- 
> Xiaofan

how do i do that with libusb? when switching form bootloader to applikation (or the other way) the device
waits 1second, then disconnects the integrated usb controller and waits 2 seconds before reseting the
device (software reset). But the libusb doesn't recognize that an reconnect happend. When i generate a
new context, i get the new device, but i guess that this shoul not be the way to do it correctly. 

> 
> You can always change the bcdDevice value.  That ought to be just as 
> good as changing the idVendor or idProduct.
> 
> Alan Stern
> 

i tried it, but still have the same problem.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

(Continue reading)

Xiaofan Chen | 16 Aug 2012 15:33

Picon

Re: Re: same productID + VendorID für application and bootloader

On Thu, Aug 16, 2012 at 9:19 PM, Christoph Sander <hondaracer1 <at> gmx.de> wrote:
> Thx for the help, but i still have open questions i hope u can help me with
>
>> It can make to work if the device detaches and then re-attaches
>> to the bus (reset or soft-detach) and the PC application search
>> for new device again when switching from bootloader to the main
>> firmware.
>>
>> --
>> Xiaofan
>
> how do i do that with libusb? when switching form bootloader to
> applikation (or the other way) the device waits 1second, then
> disconnects the integrated usb controller and waits 2 seconds
> before reseting the device (software reset). But the libusb doesn't
> recognize that an reconnect happend. When i generate a new
> context, i get the new device, but i guess that this shoul not be
> the way to do it correctly.
>

I think Peter's answer should work.
++++ from Peter Stuge's reply +++++
Unref and free the libusb_device * and call libusb_get_device_list()
again - that should not return cached data.
+++++++++++++++++++++++++++

Is your PC application in charge of the switch between
bootloader firmware and main firmware? In that case,
the above should work fine since you know when the
switching happens.

(Continue reading)

Christoph Sander | 16 Aug 2012 16:59

Picon

Picon

Re: Re: same productID + VendorID für application and bootloader

> 
> I think Peter's answer should work.
> ++++ from Peter Stuge's reply +++++
> Unref and free the libusb_device * and call libusb_get_device_list()
> again - that should not return cached data.
> +++++++++++++++++++++++++++
> 
> Is your PC application in charge of the switch between
> bootloader firmware and main firmware? In that case,
> the above should work fine since you know when the
> switching happens.
> 

I thought, calling the close command für a device, is the same like calling unref (in the case that ref
wasn't called for the device). I will try it and let u know if its works as workaround for me.
within the libusb 1.0 api, there is no free command, so i guess the libusb will do the free automatically if
unref is called for the device.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusb-devel mailing list
libusb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Christoph Sander | 16 Aug 2012 17:42

Picon

Picon

Re: Re: same productID + VendorID für application and bootloader

> 
> I think Peter's answer should work.
> ++++ from Peter Stuge's reply +++++
> Unref and free the libusb_device * and call libusb_get_device_list()
> again - that should not return cached data.
> +++++++++++++++++++++++++++
> 
> Is your PC application in charge of the switch between
> bootloader firmware and main firmware? In that case,
> the above should work fine since you know when the
> switching happens.
> 

i tried calling unref for the device (after switching to bootloader and closing the devicehandle), but it
did not fix the problem i have. Is there a free command i am missing, and should call to clear the cashed data
for a device?

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Peter Stuge | 17 Aug 2012 00:39

Picon

Re: same productID + VendorID für application and bootloader

Christoph Sander wrote:
> when switching form bootloader to applikation (or the other way)
> the device waits 1second, then disconnects the integrated usb
> controller and waits 2 seconds before reseting the device (software
> reset). But the libusb doesn't recognize that an reconnect happend.

Note that there is no concept of reconnect in USB. Either a device is
connected or it is disconnected. If a device gets disconnected and
the same device gets connected again then it is really just a new
device being connected which was previously not connected. Does that
make sense?

The point is that when the device disconnects, the libusb_device and
possibly opened libusb_device_handle still represent the disconnected
device. If you attempt to do IO you will get LIBUSB_ERROR_NO_DEVICE
back.

The same physical device connecting back with or without identical
descriptors needs to be found by libusb before it can be used again.

Calling libusb_get_device_list() will get you a fresh list of
devices.

In your original email it seemed like you were changing descriptors
without disconnecting the device. Since you disconnect the device
there should be no problem at all.

Please see if you can share a small program which demonstrates the
problem. I think it will help clear up all the questions.

(Continue reading)

Christoph Sander | 17 Aug 2012 01:12

Picon

Picon

Re: same productID + VendorID für application and bootloader


> Calling libusb_get_device_list() will get you a fresh list of
> devices.
when i generate a new context first, i get the new device after the reconnect. but if i work with the same
context (ctx from init command) then i get the old device again, like it is cashed within the context and is
not deleted correctly when preforming an reconnect

> In your original email it seemed like you were changing descriptors
> without disconnecting the device. Since you disconnect the device
> there should be no problem at all.
i preform a disconnect on the device, and also do a reset of the device(softwarereset of the mikrocontroller).

> Please see if you can share a small program which demonstrates the
> problem. I think it will help clear up all the questions.
>

i will do that today, as good as i can. The program is a little bit bigger, so i have to put some time in writing an
gut example to show what i am doing.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Christoph Sander | 2 Oct 2012 13:14

Picon

Picon

Problem after 1000 calls of libusb_get_device_list

Hi,

I guess the code will say more then thousand words, so:

long ctx;
Usb_Device device;
ctx = LibusbJava1.libusb_init();
for (int k = 0; k <  1000000; k++)
{
   System.out.println(" ********************************** " + k);
   device = LibusbJava1.libusb_get_device_list((Long) ctx);
}

Thats all i do, and after 1300 calls of the libusb_get_device_list(ctx) command, the Java runtime
collapses. Does anyone got this problem with the libusb, or does it have to be a problem with the Java wrapper?

Environment:
Windows 7 64bit
JRE 1.7
libusb1.0 + Javawrapper
Windows backend (http://www.libusb.org/wiki/windows_backend)

i also tried:
long ctx;
Usb_Device device;
ctx = LibusbJava1.libusb_init();
for (int k = 0; k <  1000000; k++)
{
   System.out.println(" ********************************** " + k);
   Thread.sleep(500);

(Continue reading)

Tormod Volden | 2 Oct 2012 14:01

Picon

Re: Problem after 1000 calls of libusb_get_device_list

On Tue, Oct 2, 2012 at 1:14 PM, Christoph Sander wrote:
> Hi,
>
> I guess the code will say more then thousand words, so:
>
> long ctx;
> Usb_Device device;
> ctx = LibusbJava1.libusb_init();
> for (int k = 0; k <  1000000; k++)
> {
>    System.out.println(" ********************************** " + k);
>    device = LibusbJava1.libusb_get_device_list((Long) ctx);
> }
>
>
> Thats all i do, and after 1300 calls of the libusb_get_device_list(ctx) command, the Java runtime
collapses. Does anyone got this problem with the libusb, or does it have to be a problem with the Java wrapper?

Hi Chris,

Did you see the libusb_get_device_list() documentation on
http://libusb.sourceforge.net/api-1.0/group__dev.html ?
"You are expected to unreference all the devices when you are done
with them, and then free the list with libusb_free_device_list()."

So in your case you are allocating lots of lists without freeing them.
I am bit surprised you get trouble already after 1300 calls, but I
don't know what overhead Java adds to it.

Best regards,

(Continue reading)

Christoph Sander | 2 Oct 2012 14:43

Picon

Picon

Re: Problem after 1000 calls of libusb_get_device_list

> Hi Chris,
> 
> Did you see the libusb_get_device_list() documentation on
> http://libusb.sourceforge.net/api-1.0/group__dev.html ?
> "You are expected to unreference all the devices when you are done
> with them, and then free the list with libusb_free_device_list()."
> 
> So in your case you are allocating lots of lists without freeing them.
> I am bit surprised you get trouble already after 1300 calls, but I
> don't know what overhead Java adds to it.
> 
> Best regards,
> Tormod

Thx for the fast response.
Is this command part of a new release? Because the Java wrapper doesn't support this command in any kind.

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

Peter Stuge | 2 Oct 2012 17:52

Picon

Re: Problem after 1000 calls of libusb_get_device_list

Hi Chris,

Christoph Sander wrote:
> > "You are expected to unreference all the devices when you are done
> > with them, and then free the list with libusb_free_device_list()."
> 
> Thx for the fast response.
> Is this command part of a new release?

No, libusb_free_device_list() was added at the same time as
libusb_get_device_list(), in:

commit 9cfdb494fccac53a4277da7c8b6d15f1a72a4959
Author: Daniel Drake <dsd <at> gentoo.org>
Date:   Thu Mar 6 23:25:20 2008 +0000

    Rework device discovery API

> Because the Java wrapper doesn't support this command in any kind.

See if you can get in touch with the authors of the wrapper?

Maybe the list is freed when the returned object is destroyed, but I
would naively expect the JVM GC to clean up in your code, in that
case.

Anyway, find out how to free the list in the wrapper.

But more interesting: Why do you need to call the function so many times?

(Continue reading)

Christoph Sander | 2 Oct 2012 22:27

Picon

Picon

Re: Problem after 1000 calls of libusb_get_device_list


> > Because the Java wrapper doesn't support this command in any kind.
> 
> See if you can get in touch with the authors of the wrapper?
> 
> Maybe the list is freed when the returned object is destroyed, but I
> would naively expect the JVM GC to clean up in your code, in that
> case.
> 
> Anyway, find out how to free the list in the wrapper.

I will, thanks for the help.

> 
> But more interesting: Why do you need to call the function so many times?
> 
the software connects to medical sensors, and there must be no limit for the number of devices the software
can work with, except the limitation by the usb standard. 

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

Peter Stuge | 2 Oct 2012 22:32

Picon

Re: Problem after 1000 calls of libusb_get_device_list

Christoph Sander wrote:
> > Anyway, find out how to free the list in the wrapper.
> 
> I will, thanks for the help.

You're welcome. I'm actually also curious about what the solution
turns out to be.

> > But more interesting: Why do you need to call the function so
> > many times?
> 
> the software connects to medical sensors, and there must be no
> limit for the number of devices the software can work with, except
> the limitation by the usb standard. 

But you only need one call to libusb_get_device_list() in order to
enumerate all connected devices in the system.

//Peter

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

Christoph Sander | 3 Oct 2012 09:58

Picon

Picon

Re: Problem after 1000 calls of libusb_get_device_list


> > > But more interesting: Why do you need to call the function so
> > > many times?
> > 
> > the software connects to medical sensors, and there must be no
> > limit for the number of devices the software can work with, except
> > the limitation by the usb standard. 
> 
> But you only need one call to libusb_get_device_list() in order to
> enumerate all connected devices in the system.

yes, and everytime a new device gets connected to the system, and in my case every time i perform a
firmwareupdate for one of the connected devices, to switch from application to bootloader. 

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

Xiaofan Chen | 3 Oct 2012 11:34

Picon

Re: Problem after 1000 calls of libusb_get_device_list

On Wed, Oct 3, 2012 at 3:58 PM, Christoph Sander <hondaracer1 <at> gmx.de> wrote:
>
>> > > But more interesting: Why do you need to call the function so
>> > > many times?
>> >
>> > the software connects to medical sensors, and there must be no
>> > limit for the number of devices the software can work with, except
>> > the limitation by the usb standard.
>>
>> But you only need one call to libusb_get_device_list() in order to
>> enumerate all connected devices in the system.
>
> yes, and everytime a new device gets connected to the system,
> and in my case every time i perform a firmwareupdate for one of the
> connected devices, to switch from application to bootloader.
>

I see. In that case, you kind of need hotplug support which is
not implemented in libusb yet. But there are recent discussions
about this here in this mailing list.
http://libusb.6.n5.nabble.com/libusb-context-tt5710685.html

For libusbx, hotplug support is planned in the future
(6 months later).
https://github.com/libusbx/libusbx/issues/milestones?direction=asc&sort=due_date

--

-- 
Xiaofan

------------------------------------------------------------------------------

(Continue reading)

Tormod Volden | 3 Oct 2012 13:02

Picon

Re: Problem after 1000 calls of libusb_get_device_list

On Wed, Oct 3, 2012 at 9:58 AM, Christoph Sander wrote:
>
>> > > But more interesting: Why do you need to call the function so
>> > > many times?
>> >
>> > the software connects to medical sensors, and there must be no
>> > limit for the number of devices the software can work with, except
>> > the limitation by the usb standard.
>>
>> But you only need one call to libusb_get_device_list() in order to
>> enumerate all connected devices in the system.
>
> yes, and everytime a new device gets connected to the system, and in my case every time i perform a
firmwareupdate for one of the connected devices, to switch from application to bootloader.

After detecting new devices, and getting a device handle through
libusb_open(), you can keep the handle while you free the device list.
This leaves you with the challenge of determining which devices are
actually new in the new device list. I am not sure if you can use
libusb_get_device() to compare existing handles against the new
devices, or if you have to match against some more persistent
attributes of your devices, like the bus and bus address tuple
(available through libusb_get_bus_number() and
libusb_get_device_address()) or the serial number of your device.

Tormod

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly

(Continue reading)

Robert Heller | 2 Oct 2012 15:39

Re: Problem after 1000 calls of libusb_get_device_list

At Tue, 2 Oct 2012 14:01:27 +0200 Tormod Volden <lists.tormod <at> gmail.com> wrote:

> 
> On Tue, Oct 2, 2012 at 1:14 PM, Christoph Sander wrote:
> > Hi,
> >
> > I guess the code will say more then thousand words, so:
> >
> > long ctx;
> > Usb_Device device;
> > ctx = LibusbJava1.libusb_init();
> > for (int k = 0; k <  1000000; k++)
> > {
> >    System.out.println(" ********************************** " + k);
> >    device = LibusbJava1.libusb_get_device_list((Long) ctx);
> > }
> >
> >
> > Thats all i do, and after 1300 calls of the libusb_get_device_list(ctx) command, the Java runtime
collapses. Does anyone got this problem with the libusb, or does it have to be a problem with the Java wrapper?
> 
> Hi Chris,
> 
> Did you see the libusb_get_device_list() documentation on
> http://libusb.sourceforge.net/api-1.0/group__dev.html ?
> "You are expected to unreference all the devices when you are done
> with them, and then free the list with libusb_free_device_list()."
> 
> So in your case you are allocating lots of lists without freeing them.
> I am bit surprised you get trouble already after 1300 calls, but I

(Continue reading)

Xiaofan Chen | 3 Oct 2012 11:29

Picon

Re: Problem after 1000 calls of libusb_get_device_list

On Tue, Oct 2, 2012 at 7:14 PM, Christoph Sander <hondaracer1 <at> gmx.de> wrote:
> Environment:
> Windows 7 64bit
> JRE 1.7
> libusb1.0 + Javawrapper
> Windows backend (http://www.libusb.org/wiki/windows_backend)

Are you using the Java wrapper here?
http://sourceforge.net/projects/libusbjava/

>From what I see, it seems to use rather old version of
libusb-1.0.
http://libusbjava.svn.sourceforge.net/viewvc/libusbjava/trunk/LibusbJava/

Maybe you want to rebuild the Java Wrapper with the latest version
of libusb.git (not libusb-1.0.9 release which has many Windows bugs)
or libusbx 1.0.14 release Windows binary which is a libusb fork.
http://sourceforge.net/projects/libusbx/files/releases/1.0.14/Windows/

--

-- 
Xiaofan

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

Christoph Sander | 3 Oct 2012 14:02

Picon

Picon

Re: Problem after 1000 calls of libusb_get_device_list


> Are you using the Java wrapper here?
> http://sourceforge.net/projects/libusbjava/
> 
> From what I see, it seems to use rather old version of
> libusb-1.0.
> http://libusbjava.svn.sourceforge.net/viewvc/libusbjava/trunk/LibusbJava/
> 
> Maybe you want to rebuild the Java Wrapper with the latest version
> of libusb.git (not libusb-1.0.9 release which has many Windows bugs)
> or libusbx 1.0.14 release Windows binary which is a libusb fork.
> http://sourceforge.net/projects/libusbx/files/releases/1.0.14/Windows/
> 
> 
> -- 
> Xiaofan
yes, but the libusb version the wrapper is build against is from march 2012. So it isn't the newest but still
not as old as the version on the sourceforge side. I will build it with the newest version of the libusb and
inplement the free device list command. I hope this will fix my problem

> After detecting new devices, and getting a device handle through
> libusb_open(), you can keep the handle while you free the device list.
> This leaves you with the challenge of determining which devices are
> actually new in the new device list. I am not sure if you can use
> libusb_get_device() to compare existing handles against the new
> devices, or if you have to match against some more persistent
> attributes of your devices, like the bus and bus address tuple
> (available through libusb_get_bus_number() and
> libusb_get_device_address()) or the serial number of your device.
>

(Continue reading)

Return

Return to gmane.comp.lib.libusb.devel.general.

Project Web Page

Discussion about the development of the cross-platform user space library for accessing usb devices.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane