RE: [PATCH] serial.c procfs kudzu - discussion

[Ed Vance <EdV@macrolink.com>]

On Fri Mar 08, 2002, Ed Vance wrote:
> 
> On Fri Mar 08, 2002, Russell King wrote:
> > 
> > 2. "port:" entry being 0.  I don't think we really want to report IO
> >    port or memory addresses here without giving userspace some
> >    indication which we're reporting.
> > 
> > For 2, I'd suggest replacing "port:" with "mem:" for iomem ports, and
> > changing the serinfo: line to reflect the changed format (this is
> > probably ignored by kudzu though.)
> >
> Yes. I'll change the serinfo line rev marking from 1.0 to 1.1 and label 
> the  iomem value as "mem". If I remember correctly, kudzu detects that 
> field by its delimiters, so it does not matter that we change the field 
> label. It's probably easiest for me to verify by just trying it. If there 
> is a surprise there, I will inform Bill Nottingham at Red Hat. 

Bill,

I did not remember kudzu's parsing of the "port" field as well as I thought.

It does a string match against the first three labels, "uart", "port", and 
"irq". So, if I change the second label to "mem" for ports that are mapped 
into memory space, then it will break kudzu. In function InitSerials(), 
pointer variable "port" becomes null at pciserial.c:61 and causes strchr() 
to explode at line pciserial.c:71. (kudzu-0.99.23 from Red Hat 7.2) 

The only way we could differentiate I/O and memory addresses without 
breaking the current kudzu (that I could think of at my present caffeine 
level) would be to leave it "port" and output four hex digits for I/O 
addresses and eight digits for memory addresses. (just a bit ugly)

All,

Is this correction of information presented to the user from the driver 
worth changing kudzu? Opinions please. 

Best regards,
Ed Vance