Re: [PATCH v2 18/19] drivers: mem: Create file to access second half of 64-bit memory

From: Peter Mamonov <pmamonov@gmail.com>
To: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Barebox List <barebox@lists.infradead.org>
Subject: Re: [PATCH v2 18/19] drivers: mem: Create file to access second half of 64-bit memory
Date: Fri, 1 Feb 2019 13:14:09 +0300	[thread overview]
Message-ID: <20190201101408.dj66i7lsfceteve5@localhost.localdomain> (raw)
In-Reply-To: <CAHQ1cqH=nccB4+ztNE+LfRus3E+6N=6SC3a1pkkFgeoYkVhYoQ@mail.gmail.com>

On Thu, Jan 31, 2019 at 12:17:08PM -0800, Andrey Smirnov wrote:
> On Thu, Jan 31, 2019 at 2:55 AM Peter Mamonov <pmamonov@gmail.com> wrote:
> >
> > Hello, Andrey,
> >
> > > In order to allow access to second half of address space on 64-bit
> > > machines, add code that creates /dev/highmem dedicated for that.
> > >
> > > Note that due to maximum file size being limited to MAX_LFS_FILESIZE
> > > or 0x7fff_ffff_ffff_ffff bytes at addresses 0x7fff_ffff_ffff_ffff and
> > > 0xffff_ffff_ffff_ffff cannot be access through /dev/mem and
> > > /dev/hightmem correspondingly.
> >
> > Does it imply using `-s /dev/highmem` argument when accessing addresses beyond
> > MAX_LFS_FILESIZE?
> 
> Yes, it does.
> 
> > That's not very convenient:
> >
> >         $ git grep -l /dev/mem
> >         commands/crc.c
> >         commands/digest.c
> >         commands/disasm.c
> >         commands/md.c
> >         commands/memcmp.c
> >         commands/memcpy.c
> >         commands/memset.c
> >         commands/mm.c
> >         commands/mw.c
> >
> 
> I don't disagree, but there isn't much that can be done about that
> AFAICT. The first version of this fix kept single /dev/mem file, but
> ended up introducing quite a bit of special cases all over the FS
> layer, so it was rejected. The only two options to make it more
> convenient that I can see would be to either modify "/dev/mem" users
> to make "/dev/highmem" substitution automatically based on offset they
> are given, or, assuming it is possible, create a mapping that would
> expose all of the interesting registers on MIPS64 in the lower half of
> 64-bit address space.

Guess we can just adopt Linux's approach. Linux recognizes /dev/mem's lseek as
a special case and has a dedicated implementation for it. Here is a relevant
comment from drivers/char/mem.c:

	/*
	 * The memory devices use the full 32/64 bits of the offset, and so we cannot
	 * check against negative addresses: they are ok. The return value is weird,
	 * though, in that case (0).
	 *
	 * also note that seeking relative to the "end of file" isn't supported:
	 * it has no meaning, so it returns -EINVAL.
	 */
	static loff_t memory_lseek(struct file *file, loff_t offset, int orig)
	{

Regards,
Peter

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox