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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 15 2002 - 22:00:11 EST