Date: Mon, 24 Feb 2003 15:24:28 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <3E5AA9AC.64576E06@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> <20030224225324.GB1032@athlon.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar wrote: > On Mon, Feb 24, 2003 at 02:06:47PM -0800, Terry Lambert wrote: > > 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 isn't really a scalability issue. If the default case is accepted to be "supported if the bus it attaches to is supported", then the files are going to be small because the exception matrix is going to be very sparse. > > 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. The base case is "compile it on the platform". The case that was the start of this thread was making SPARC64 LINT cleanly. I don't know if this was a result of "make universe" on an i386, or a "make world" on a SPARC64, though I suspect the latter. The next case is "turn it off if the kernel panic's in that code over an alignment error or some other problem". I don't think that there's any way short of running to catch runtime problems. The "turn it off" case should only be on a compilation failure, or a runtime failure when the hardware isn't present, or a runtime failure when the hardware *is* present... in that order. I view a "nodevice" entry in one of these files as nothing more than a comment that says "This needs to be worked on, but rather than work on it, I'm going to ignore it for now and work on something else I consider more important, such as rolling a release without bt(4) support at this time". There's really no other excuse for having a "nodevice" at all, if the thing is truly not architecture specific. > 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. That would be nice, but you can't catch alignment errors, except at runtime. The only two choices there are: (1) turn on the bit in 486/586 to make it bit about alignment or (2) fixup all alignment errors by default on platforms that cause alignment faults. > > 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. Options and hints are only an issue when a namespace collision occurs. This may be an issue at some point in the future, but it is not an issue now. For sure, it will be caught as a different problem altogether, if the global definition is shadowed by an architecture specific definition, in any case, so it will be caught (i.e. you have to have a bus designator to have a hint). Personally, I *like* the idea that "everything is expected to work everywhere, and exceptions to this rule require explicitly noted exceptions", which is what comes out of making it a set of global rules with exceptions, rather than a set of per platform rules. > > 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. Give away PPC code commit bits in crackerjack boxes. If you are having trouble getting PPC volunteers, lower the bar on what it takes for the project to permit someone to volunteer in that area. If you want to argue history, we're back to acknowledging that non-i386 platforms are second class citizens. You *can't* reasonably expect me to make a driver work on hardware I don't own, if I'm a driver writer. I don't care if it *is* "PCI", I'm not going to catch alignment problems if my hardware doesn't catch alignment problems, and I'm not going to be able to write PPC or Alpha asm() statements, just because I can do them for i386. The *best* you can *possibly* hope for is that I'll have 1TB of disk an a 3THz processor lying around, and be willing to do a "make universe" to check and see if it at least compiles (that's an exaggeration, but it's one based in fact: most people do not have the resources to do a "make universe" as a compilability test for a new driver). -- Terry 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?3E5AA9AC.64576E06>