[lkml]   [2000]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: BLKSSZGET change will break fdisk

On Tue, 17 Oct 2000, Andries Brouwer wrote:

> But you see that one would need a new name as well,
> otherwise the value associated with BLKSSZGET would
> depend on the kernel version, and one would need
> version checks anyway.

We do rename structures too, and this would be similiar. I'm more
concerned about binary compability. If anyone uses BLKSSZGET (for
whatever reason) it should not suddenly change the behaviour.
Why should one need version checks? If someone really needs that ioctl, he
has to copy that define, anyway, so his copy will still have the old value
(and behaviour).

> I think all this is too unimportant. Almost nobody uses
> this stuff, and 2.4 is correct, and we may fix 2.2 one
> of these days, perhaps for 2.2.19, and we may fix *fdisk
> to correctly use it.

But I also want to patch 2.2.17 or earlier kernels, but I don't want a
fdisk that breaks on these kernels.

> (By the way, have you checked that replacing get_sectorsize
> by an empty routine, and specifying a -b option, works well?)

No, not yet.

> (Do you know which disks have unusual sector size?
> So far I had only seen reports on a Fujitsu 640 MB.
> Have you seen other sectorsizes than 512, 1024, 2048
> on non-IBM disks?)

No, I didn't see anything else.

bye, Roman

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.067 / U:0.592 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site