Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Feb 2003 14:53:24 -0800
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        freebsd-arch@FreeBSD.ORG
Subject:   Re: [RFC] splitting of conf/NOTES
Message-ID:  <20030224225324.GB1032@athlon.pn.xcllnt.net>
In-Reply-To: <3E5A9777.F951598@mindspring.com>
References:  <20030224001644.GA67255@dragon.nuxi.com> <20030224120037.D4403-100000@gamplex.bde.org> <20030224023118.GD67312@dragon.nuxi.com> <3E59E8F4.884C9160@mindspring.com> <20030224100336.GB21088@athlon.pn.xcllnt.net> <3E59F665.DCD54EAF@mindspring.com> <20030224191209.GA559@athlon.pn.xcllnt.net> <3E5A9777.F951598@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 24, 2003 at 02:06:47PM -0800, Terry Lambert wrote:

> > > I think people need to fact the fact that i386 is the FreeBSD
> > > reference platform, and all other platforms are second class
> > > citizens.
> > 
> > Our i386 platform is still the best maintained and supported.
> > This however doesn't contribute anything to a possible solution
> > other than to indicate that a i386 centric solution at the
> > cost of non-i386 platforms is acceptable. I disagree...
> 
> So do I, which is why I believe *everything* should be present by
> default, and have to be "commented out" on a per platform basis.

I think a scheme to create a couple of buckets and define the
inclusion or exclusion based on those buckets generally scales
better. We already have that now in the form of MI/MD buckets,
but this scheme does not work well, because drivers hardly
ever are truly MI and/or truly MD.

> This also gives control to the platform maintainer over the decision
> of whether or not they are going to make something work on, for
> example, the PPC, or if they are going to add a "nodevice" entry to
> the /sys/ppc/conf/NOTES file to dike it out -- *only for the PPC*.

I think in practice that platform maintainers will base their
decision on the busses to which a driver can attach. I for one
don't know how else to determine if a driver can work on a
particular platform. One might as well use a system that does
this by design (or allows this to be done by policy) and thus
avoid X platform maintainers (given X platforms) to have to make
the deduction manually.

> This also supports the philosophy that *you* stated, at one point,
> where if something is a PCI driver, it should be present on all
> PCI systems, except those it specifically is known to not work on.

The condition "if something is a PCI driver" is already a selection
that has happened before the "nodevice" filtering. people object
to having such an a priori selection and propose a solution on
nodevice only. I argue that the preselection is good. I did not
state that I reject nodevice as a mechanism to handle the exception,
although I did state that nodevice is flawed in that it doesn't
deal with options and hints.

> If maintaining these per-architecture "nodevice" lists starts to
> become cumbersome, then there's an easy answer: attract more
> volunteers for that platform, and start fixing the drivers to
> make them work, so you can remove the "nodevice" lines.

I think this is unrealistic and I think that we only have to look
at the current state of affairs and our history (or the history
of drivers) to see the proof of it.

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel@xcllnt.net

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




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