On Wed, Sep 18, 2019 at 1:45 PM Greg KH <gre...@linuxfoundation.org> wrote:
>
> On Wed, Sep 18, 2019 at 01:22:42PM +0200, Yegor Yefremov wrote:
> > On Wed, Sep 18, 2019 at 1:08 PM Greg KH <gre...@linuxfoundation.org> wrote:
> > >
> > > On Wed, Sep 18, 2019 at 11:14:15AM +0200, yegorsli...@googlemail.com 
> > > wrote:
> > > > From: Yegor Yefremov <yegorsli...@googlemail.com>
> > > >
> > > > Add additional port statistics like received and transmitted bytes
> > > > the way /proc/tty/driver/serial does.
> > > >
> > > > As usbserial driver already provides USB related information and
> > > > this line is longer than 100 characters, this patch adds an
> > > > additional line with the same port number:
> > > >
> > > > 0: module:ftdi_sio name:"FTDI USB Serial Device" vendor:0403 ...
> > > > 0: tx:112 rx:0
> > > >
> > > > Signed-off-by: Yegor Yefremov <yegorsli...@googlemail.com>
> > > > ---
> > > >  drivers/usb/serial/usb-serial.c | 22 ++++++++++++++++++++++
> > > >  1 file changed, 22 insertions(+)
> > >
> > > You can't change existing proc files without having the chance that
> > > userspace tools will break.
> > >
> > > Have you tried this and seen what dies a horrible death?
> >
> > This patch is more a proof of concept (forgot to add RFC keyword). I
> > find statistics provdes by the 8250 driver very useful for debugging
> > purposes. What would be the best way to implemnt this feature for
> > usbserial driver?
> >
> > a) extend current line:
> >
> > 0: module:ftdi_sio name:"FTDI USB Serial Device" vendor:0403 ...tx:112 rx:0
> >
> > though this still can break parsing
> >
> > b) creating special entries for FTDI and other UARTs? Though it would
> > be greate to have all usbserial UART handled the same way in the same
> > file
>
> Why is any of this needed at all?  Also, be very aware of the security
> issues involved here, we had to disable access of these values by
> "normal" users for other tty devices, so please don't break that by
> offering it up here again.
>
> What is going to use this information?

This feature is not a "must have" one but it is convenient to see
transferred/received bytes and error flags from user space. If some
serial software is not working like expected and doesn't provide
enough debugging information one can quickly look at port statistics
from the console in order to check whether and how many bytes were
transferred or whether the were some communication errors.

Yegor

Reply via email to