cvs commit: src/sys/alpha/alpha mem.c promcons.c src/sys/alpha/tlsb zs_tlsb.c src/sys/amd64/amd64 mem.c src/sys/cam cam_xpt.c src/sys/cam/scsi scsi_ch.c scsi_pass.c scsi_pt.c s

[Poul-Henning Kamp]

In message <20040223.090922.112923872.imp at bsdimp.com>, "M. Warner Losh" writes:
>In message: <403A22BB.6010409 at freebsd.org>
>            Scott Long <scottl at FreeBSD.org> writes:
>: I agree with these arguments.  However, I would have liked to have seen
>: a small grace period defined, especially since people are now bumping
>: into the consequences of this change and not knowing why.  I plan to do
>: this with the interrupt API change when it comes.
>
>Especially since the code to do this is on the order of:
>
>	if (devsw->d_version == 0) {
>		printf("Warning, older interface ...");
>		devsw->d_flags ^= D_NEEDGIANT;
>		devsw->d_version = D_VERSION_00;
>	}
>
>unless there are other issues not elucidated (I'm only looking at the
>new code).  One could also have had two different bits so APIly it
>changed, but you could whine if only one of them was set.

The semantics of dev_t changed as a result of the refcounting, so
I would have to forcefully break all binary drivers[1] anyway.  The
above workaround would not be safe.

And since I had to break them, I decided to have only one break,
and get all three major issues fixed at the same time: dev_t
refcounting, versioning of device driver API and flipping of the
Giant flag.

And I distinctly remember being very vocal about this on current@,
so I think you guys are a little late here...

Poul-Henning

[1] Because experience have shown that the amount of dev_t/makedev(9)
evilness increases with the distance from our CVS repository.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.