Hi,
On Sun 16-03-08 04:14:58, Andrew Perepechko wrote:
> > > struct mem_dqblk {
> > > - __u32 dqb_bhardlimit; /* absolute limit on disk blks alloc */
> > > - __u32 dqb_bsoftlimit; /* preferred limit on disk blks */
> > > + qsize_t dqb_bhardlimit; /* absolute limit on disk blks alloc */
> > > + qsize_t dqb_bsoftlimit; /* preferred limit on disk blks */
> > > qsize_t dqb_curspace; /* current used space */
> > > - __u32 dqb_ihardlimit; /* absolute limit on allocated inodes */
> > > - __u32 dqb_isoftlimit; /* preferred inode limit */
> > > - __u32 dqb_curinodes; /* current # allocated inodes */
> > > + qsize_t dqb_ihardlimit; /* absolute limit on allocated inodes */
> > > + qsize_t dqb_isoftlimit; /* preferred inode limit */
> > > + qsize_t dqb_curinodes; /* current # allocated inodes */
> > > time_t dqb_btime; /* time limit for excessive disk use */
> > > time_t dqb_itime; /* time limit for excessive inode use */
> > > };
> >
> > Is there a reason to use "qsize_t" instead of just using __u64 directly?
> >
>
> Well, I'm not sure if there's a special meaning for qsize_t. I have only followed
> the dqb_curspace convention, which is of qsize_t type. While I see no
> special usage for qsize_t (well, it looks more nice than __u64 :), I at the same time
> see no problems using qsize_t. Maybe Jan will tell us more about qsize_t.
Well, when designing these structures originally, I wanted to have one
clear type for holding quota space information and so I introduced qsize_t.
Speaking about it, logically we should have a similar type for "number of
inodes" (something like qcount_t) because there is no logical connection between
number of inodes and space... But I don't really care much.
Honza
--
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
