The main users of dev_t in the userspace-kernel interface
are mknod and stat. But there is a small collection of
more obscure interfaces that use a dev_t parameter
(like the ustat system call) or a dev_t field in a
parameter struct (for example, struct loopinfo,
struct nfsctl_export, struct dm_ioctl).
It is almost always a mistake to have an interface
with a dev_t field, since nobody knows the size of
a dev_t field. The kernel size differs from the user
space size, the libc5 size differs from the glibc size.
A struct with such a field therefore has unknown size,
the fields following the dev_t field have unknown offset,
and lots of troubles arise.
Such interfaces are broken from the start.
But there are a few and we must deal with them one by one.
One is struct dm_ioctl. Google tells me that it was
noticed already that it defined a broken interface,
and Kevin Corry submitted a patch against 2.5.51.
Today this has not been applied yet.
What is the status? Should I resubmit that patch?
[http://marc.theaimsgroup.com/?l=linux-kernel&m=103956089203199&w=3]
Andries
On Wed, Mar 26, 2003 at 12:27:29PM +0100, [email protected] wrote:
> One is struct dm_ioctl. Google tells me that it was
> noticed already that it defined a broken interface,
> and Kevin Corry submitted a patch against 2.5.51.
> Today this has not been applied yet.
>
> What is the status? Should I resubmit that patch?
DM already has a pathname-based interface. Just rip out the dev_t-
based one, this will also allow to simplify the kernel code by using
the pathname to fully setuped blockdevice helpers I added to block_dev.c
On Wednesday, March 26, 2003, at 11:27 AM, [email protected] wrote:
> One is struct dm_ioctl. Google tells me that it was
> noticed already that it defined a broken interface,
> and Kevin Corry submitted a patch against 2.5.51.
> Today this has not been applied yet.
>
> What is the status? Should I resubmit that patch?
The patch is queued, and should be merged very soon. The only reason I
delayed was that I wanted to update both the 2.4 and 2.5 releases at
the same time so that people can continue to switch back and forth
between kernels. That said, I have left it too long, sorry.
- Joe
Joe Thornber <[email protected]> wrote:
>
>
> On Wednesday, March 26, 2003, at 11:27 AM, [email protected] wrote:
>
> > One is struct dm_ioctl. Google tells me that it was
> > noticed already that it defined a broken interface,
> > and Kevin Corry submitted a patch against 2.5.51.
> > Today this has not been applied yet.
> >
> > What is the status? Should I resubmit that patch?
>
> The patch is queued, and should be merged very soon. The only reason I
> delayed was that I wanted to update both the 2.4 and 2.5 releases at
> the same time so that people can continue to switch back and forth
> between kernels. That said, I have left it too long, sorry.
Please send me a copy. I'd like to get all the required bits and pieces for
this conversion queued up in one place so we can actually look at it,
evaluate its impact and test it. The current process of creeping revelations
is quite confusing.
Also if userspace tools need upgrading please send me the URLs so I can make
people well aware of the upgrade requirements and process.
Thanks.