Re: 2.5.28 and partitions

From: Anton Altaparmakov (aia21@cantab.net)
Date: Thu Jul 25 2002 - 03:43:08 EST


At 06:15 25/07/02, Linus Torvalds wrote:
>On Thu, 25 Jul 2002, Anton Altaparmakov wrote:
> >
> > >u64 for sector_t doesn't change anything for 64bit boxen that might be
> > >interested in really large disks and screws 32bit ones that shouldn't
> > >have to pay for that...
> >
> > True. That's why sector_t should be a compile time option in the kernel
> > "Enable large device support > 2TiB: Y/N". Then I am happy and loads of
> > other people because we can use large raid arrays without having to buy the
> > latest expensive system and other people are happy for having faster 32-bit
> > code... Surely we can write robust enough code which will work with either
> > sector_t size...
>
>Careful. One issue is user-level interfaces to the kernel. I would suggest
>any user level interface should use u64, not "sector_t". So that there is
>zero confusion. Clearly 64-bit sector numbers will be/are really close to
>being an issue for some people.

Of course. We do need a consistent ABI... But I don't see that as a big
problem. There aren't that many places that take sectors as arguments that
we need to fix AFAICS.

Both there and for user supplied byte offsets/sizes, we just need to check
that user supplied values are not being overflowed on 32-bit sector_t
compiled kernels... something like

         if (sizeof(sector_t) == 4) {
                 if (value & ~(((u64)1 << 32) - 1))
                         return -E2BIG;
         }

should compile out nicely for 64-bit sector_t and provide a simple, highly
optimized check for 32-bit sector_t... (If gcc optimizes it well I should
hope it will just do a simple 32-bit compare of the high 32-bits with zero...)

I have to admit that if it was just up to me, I would make sector_t
unconditionally u64, so there don't need to be checks like the above all
over the place... But that's just me... (-;

Best regards,

         Anton

-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue Jul 30 2002 - 14:00:19 EST