Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Apr 1999 01:56:41 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        current@freebsd.org, committers@freebsd.org
Subject:   About that 'new-bus' stuff.
Message-ID:  <19990412175644.7DE5F1F4F@spinner.netplex.com.au>

next in thread | raw e-mail | index | archive | help
As some have become aware, we have created a small sandbox repository
alongside (but seperate to) the main FreeBSD sources.

I've been asked a few times for info on what it is, so here's a quick
summary.  First, the background..

The original 386BSD and FreeBSD configuration interface was purely static.
ie: you filled in your config(8) file, ran config, compiled the kernel and
you were done.  It pretty much supported ISA devices only.  Back then, that
was quite reasonable as the devices stayed put and required a considerable
amount of effort to change.

But it's not 1992 anymore.  That nice cozy picture has changed somewhat.
Now, we've got multi-layer busses and all sorts of dynamic stuff that
changes on the fly (usb, pccard, cardbus being prime examples).  You end up
with scsi controllers on parallel ports, parallel printer bridges on usb,
etc.  As well, nearly all of these devices are self identifying.  PCI, PnP,
EISA etc all carry identification so the configuration can be determined by
asking the device directly.  This does not fit well into our nice static
config system any more.  The average system these days has very few or
perhaps even no devices that require configuration "assistance".

There was also the problem of duplication of information.  Drivers in the
kernel were written to attach to specific busses and the exact same
information had to be duplicated in the user's config file.  Some
alternatives (the original config.new, for example) were worse because they
added another copy - various Makefiles and rule files needed another set of
information to say the same thing again.  (As an aside, NetBSD has done
wonderful things to config.new, but it wasn't the direction we wanted to go).

And then along came the Alpha port.  Rather than being a descendent of the
old way of doing things, it was done from a different direction as it had
no isa-like bus to fight with.  It's configuration system is dynamic and
"hint" based.  The only place that hierarchy is enforced is in the drivers
themselves.  You don't need to duplicate that info in makefiles or config
files.  But you *can* be specific about something if you want.  For
example, if you wanted to wire da2 to a specific LUN on a specific bus on a
specific controller, you could.

And then along came the in-kernel linker.  The old driver mechanism on the
i386 cannot cope with this without serious hackery.  Various people decided
to take a shot at adapting the existing new-bus stuff to the i386.  Well,
it works very well, but isn't quite complete.

Since the people involved were having synchronization problems and having
trouble with large patchsets, we decided to set up a shared repository.
Since the aim was that the i386 port would use this, it was closely linked
with the freebsd repository and shared the same commit messages (the plan
was that the developers would need to know about it and that others who
were watching could see what was going on too).

Anyway, here's the basic objectives:

- remove (entirely) the need for static configuration, but still have
  *explicit* control when and as needed.  If the if_de driver only works
  on a pci bus, then there's no point requiring you to configure it
  specifically to attach to a pci bus in the kernel config file - the
  minimum information required is that you want it. :-)  Obviously an
  if_ed ISA driver needs hints about where to probe, but there is no
  reason why it can't have a built-in set of ports to try if the user
  chooses not to specify one.  Of course, it will use the users settings
  if they are given.

- ultimately, static configuration would be replaced with a boot-time
  dynamic method.  ie: you will be able to specify things like isa IO and
  irq settings in a config file in /boot.  You won't need to recompile to
  adjust the kernel settings, just edit the config file and reboot.

- It may well turn out that even a reboot isn't required and that the
  resources for isa configuration can be changed at runtime and the device
  re-probed with the new settings.

- userconfig would logically move to a fourth script in /boot, if not then
  it would merely be a resource editor.

- full resource management.  There is a single manager for resources like
  ports, interrupts, memory mappings etc.  This replaces the *horrible*
  kludges that try and figure out what's been used at present.

- minimize the disruption and workload for the developers.  Backwards
  compatability shims work quite nicely and old drivers work mostly
  without modifications and interface with the resource manager via the
  shims and new mechanisms.  (we could implement UDI this way!).  No
  bombshells blowing -current out of the water with major loss of
  functionality.

- *full* loadable module support, for all the busses.  (This won't work
  for linker set based drivers obviously, but with some tinkering, an
  isa_device style driver could be made loadable, or preloaded via
  loader(8) at least.)

- drastically reduce the role for config(8) or some replacement.  Ideally,
  once static configuration is loadable, it's sole role will be for managing
  a build of a choice of components with given compile options, both as a
  unified kernel and as loadable modules.  (A build of the kernel should
  do both the kernel and the kld's at the same time so they are in sync)

- the opportunity for other interface shims to be written.  It might be
  possible to write a netbsd-style newconfig interface shim like the
  existing old-style isa and pci shims.  This would go part of the way
  to being able to use their drivers with less hassles.  (There will be
  enough fun due to differences in bus_space and bus_dma, but that's
  another issue)

- I'm sure there's a million things I've forgotten..

Right now, the core functionality is operating nicely, but there are a few
key missing bits.  Specifically, wd.c doesn't (and can't) build, it needs
changes like the fd.c driver.  The ISA PnP and EISA code hasn't been
updated to use the new interfaces.  (Soren's new ata driver works).  The
pccard etc driver compiles but has not been updated yet.  The direction
the pccard stuff will go in isn't clear yet.

Hopefully Doug won't shoot me for misrepresenting something. :-)

Cheers,
-Peter



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990412175644.7DE5F1F4F>