On Jan 3, 7:52am, m...@eterna.com.au (matthew green) wrote: -- Subject: re: CVS commit: src/sys
| this seems strange to me. | | we have a published userland interface and you chose that | one to change? so userland apps must be fixed. it seems | much saner to me to fix the other in-kernel users to not | conflict with the published interfaces. There were 3 uses of DTYPE_ as far as disklabel constants go in the whole source tree. Two of them were ifdef'ed on a particular architecture. They were in: bad144: #ifdef __i386__ if (dp->d_type == DTYPE_SCSI) errx(1, "SCSI disks don't use bad144!"); ... This looks like a horrible accident :-) diskpart: if (dp->d_type == DTYPE_SMD && dp->d_flags & D_BADSECT && totsize == 0) { disklabel: #ifdef VAX_ALTLABELS if (lab.d_type == DTYPE_SMD && lab.d_flags & D_BADSECT && lab.d_secsize == 512) { I would be hard pressed to find live SMD disks to do badsect manipulation - and even if I could - I doubt that someone would want source compatibility for bad sector management programs :-) struct disklabel is on the way out; DTYPE_ constants referring to file descriptors are a much more popular API even if they are supposed to be kernel only constants... christos