From: Michael E Brown <michael_e_brown@dell.com>
To: Ben LaHaise <bcrl@redhat.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] blkgetsize64 ioctl
Date: Thu, 30 Aug 2001 12:34:31 -0500 (CDT) [thread overview]
Message-ID: <Pine.LNX.4.33.0108301226260.1213-100000@blap.linuxdev.us.dell.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0108301306300.12593-100000@toomuch.toronto.redhat.com>
On Thu, 30 Aug 2001, Ben LaHaise wrote:
> No, that's not what's got me miffed. What is a problem here is that an
> obvious next to use ioctl number in a *CORE* kernel api was used without
> reserving it. AND PEOPLE SHIPPED IT! I for one don't go about shipping
> new ABIs without reserving at least a placeholder for it in the main
> kernel (or stating that the code is not bearing a fixed ABI). If the
> ioctl # was in the main kernel, this mess would never have happened even
> with the accidental shipping of the patch in e2fsprogs. I just hope
> people will remember this in the future. ABI compatibility is not that
> hard if it's thought about.
Ok. I can agree with that. As a junior kernel hacker, I did not know about
this issue, and I agree that somebody with a bit more experience should
have reserved the next number. Sorry :-(
But, since I've gone through this ioctl reservation conflict twice now
(e2fsprogs and something having to do with XFS), I think this is a more
general problem.
As a side note, a copy of the second edition of "Linux Device Drivers" I
am using doesn't mention this idea of reserving ioctl numbers.
--
Michael Brown
Linux OS Development
Dell Computer Corp
If each of us have one object, and we exchange them,
then each of us still has one object.
If each of us have one idea, and we exchange them,
then each of us now has two ideas.
next prev parent reply other threads:[~2001-08-30 17:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-30 16:11 [PATCH] blkgetsize64 ioctl Michael E Brown
2001-08-30 16:25 ` Ben LaHaise
2001-08-30 16:44 ` Michael E Brown
2001-08-30 16:47 ` Ben LaHaise
2001-08-30 17:02 ` Michael E Brown
2001-08-30 17:12 ` Ben LaHaise
2001-08-30 17:34 ` Michael E Brown [this message]
2001-08-30 18:51 ` Theodore Tso
2001-08-30 19:03 ` Alan Cox
2001-08-30 19:10 ` Michael E Brown
2001-08-30 19:18 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2001-08-31 1:15 Andries.Brouwer
2001-08-31 1:23 ` Alan Cox
2001-08-30 11:57 Andries.Brouwer
2001-08-29 22:45 Ben LaHaise
2001-08-30 0:03 ` David S. Miller
2001-08-30 0:16 ` Ben LaHaise
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.33.0108301226260.1213-100000@blap.linuxdev.us.dell.com \
--to=michael_e_brown@dell.com \
--cc=bcrl@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).