Re: resource.c iotable_size too small (fwd)
Dan Hollis (goemon@sasami.anime.net)
Mon, 14 Apr 1997 23:47:59 -0700 (PDT)
On Tue, 15 Apr 1997, Doug Ledford wrote:
> > On Mon, 14 Apr 1997, Dan Hollis wrote:
> > > I increased the size to 80, which fixed the problem. From what I can
> > > figure, this takes only 256 more bytes in the kernel (assuming the extra
> > > iotable port space is unused). Is there any problem with making this
> > > standard?
> > Everytime my memory-challenged test-target hears "...more bytes in the
> > kernel" it makes a quiet "Ekk" sound...:)
> >
> > The current limit is on the low-side for systems with terminal servers.
> Actually, not really. It's only on the low side if your serial io
> ports are registered one at a time. One the other hand, if you have,
> say, 192 serial ports on a few intelligent cards, then you only end up
> with three io region requests (in my particular case) and no problems.
> I think that rather few systems out there are going to add enough
> devices that fall under this "Added one at a time" category to warrant
> such a change in the kernel. The existing table is really overkill for
> the typical user system and only becomes a problem on servers that use
> certain, specific brands/make of hardware.
Such as Boca 2016's, which seem to be becoming *much* more commonly used.
Yes, go ahead, hold your nose, make your snide comments and remarks, and
go fondle your Rocketport and Cyclades boards ;-)
The Boca 2016 works fine for us. A dx4/100 seems to do nicely as a 64
port terminal server. I can't imagine I'm the first person to try to put
64 Boca 2016 ports in a single PC. In fact, I *know* I'm not.
So basically everyone who wants to do this is SOL unless they know enough
to hack the kernel. "Use the source, luke" is *not* always the proper
answer. I thought the idea here was to make Linux *more* accessable to
unusual hardware configurations.
Can we at least make this some sort of compile time option? It gets rather
tiring to have to patch serial.c and resource.c for every release.
-Dan