Re: [PATCH 2/2] define mt_fileno and mt_fileno struct mtget members as mt_blkno

[Rich Felker <dalias@libc.org>]

On Fri, Jun 07, 2019 at 07:58:29AM +0200, Petr Vorel wrote:
> Hi Rich,
> 
> > > ....
> > > > > +++ b/include/sys/mtio.h
> > > > > @@ -54,8 +54,8 @@ struct mtget {
> > > > >  	long mt_dsreg;
> > > > >  	long mt_gstat;
> > > > >  	long mt_erreg;
> > > > > -	int mt_fileno;
> > > > > -	int mt_blkno;
> > > > > +	daddr_t mt_fileno;
> > > > > +	daddr_t mt_blkno;
> > > ....
> 
> > > > Can you explain what problem this is supposed to fix? It definitely
> > > > needs further discussion to determine what the right way is, but
> > > > that's impossible without knowing the problem you're trying to solve.
> > > Thanks for review. Not a problem for me actually. I've noticed, that glibc (and
> > > thus uclibc-ng) and bionic follow kernel sources, which defines it long for mips
> > > (and for sparc, but musl doesn't support it). Default is int [2]. Drop this
> > > patch if this is not an issue.
> 
> > Well it might be a problem on some archs. I think it's worth looking
> > into. We might need to add bits/mtio.h to define it appropriately for
> > the arch.
> I'd be for bits/mtio.h as I suppose this problem still persists on mips.
> But I'm not able to verify, just follow what it's defined in
> kernel/glibc/uclibc/bionic.
> 
> My main concern is to have daddr_t defined in musl.

I don't follow why this is your goal/concern. It's not a standard
type, but some historical baggage from the 70s or 80s that some
implementations carried forward. It doesn't seem to meet any of musl's
criteria for inclusion.

If you think this is incorrect, please explain why you think it's
important to have it rather than just assuming it is.

Rich