On Wed, Sep 18, 2019 at 01:51:29PM +0200, Yegor Yefremov wrote: > On Wed, Sep 18, 2019 at 1:45 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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 <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > On Wed, Sep 18, 2019 at 11:14:15AM +0200, yegorslists@xxxxxxxxxxxxxx wrote: > > > > > From: Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx> > > > > > > > > > > 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 <yegorslists@xxxxxxxxxxxxxx> > > > > > --- > > > > > 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. Again, it's a security issue, so be careful about this. If you _REALLY_ need it, make it a debugfs file, readble by root only. Or a tracepoint, and then you can have a userspace read the data using ebpf :) thanks, greg k-h
