Hello,
Patrik Mochel noticed that fs/aio.c doesn't compile on a non-highmem config.
The patch below (and in the bk tree on master.kernel.org:/home/bcrl/aio-2.5)
fixes that by making the helper functions #defines, and should also be a
bit faster.
-ben
:r ~/patches/v2.5.31-aio-nohighmem.diff
diff -urN linux-2.5/fs/aio.c linux-2.5.aio/fs/aio.c
--- linux-2.5/fs/aio.c Mon Aug 26 17:03:12 2002
+++ linux-2.5.aio/fs/aio.c Mon Aug 26 17:42:54 2002
@@ -174,29 +174,24 @@
/* aio_ring_event: returns a pointer to the event at the given index from
* kmap_atomic(, km). Release the pointer with put_aio_ring_event();
*/
-static inline struct io_event *aio_ring_event(struct aio_ring_info *info, int nr, enum km_type km)
-{
- struct io_event *events;
#define AIO_EVENTS_PER_PAGE (PAGE_SIZE / sizeof(struct io_event))
#define AIO_EVENTS_FIRST_PAGE ((PAGE_SIZE - sizeof(struct aio_ring)) / sizeof(struct io_event))
+#define AIO_EVENTS_OFFSET (AIO_EVENTS_PER_PAGE - AIO_EVENTS_FIRST_PAGE)
- if (nr < AIO_EVENTS_FIRST_PAGE) {
- struct aio_ring *ring;
- ring = kmap_atomic(info->ring_pages[0], km);
- return &ring->io_events[nr];
- }
- nr -= AIO_EVENTS_FIRST_PAGE;
+#define aio_ring_event(info, nr, km) ({ \
+ unsigned pos = (nr) + AIO_EVENTS_OFFSET; \
+ struct io_event *__event; \
+ __event = kmap_atomic( \
+ (info)->ring_pages[pos / AIO_EVENTS_PER_PAGE], km); \
+ __event += pos % AIO_EVENTS_PER_PAGE; \
+ __event; \
+})
- events = kmap_atomic(info->ring_pages[1 + nr / AIO_EVENTS_PER_PAGE], km);
-
- return events + (nr % AIO_EVENTS_PER_PAGE);
-}
-
-static inline void put_aio_ring_event(struct io_event *event, enum km_type km)
-{
- void *p = (void *)((unsigned long)event & PAGE_MASK);
- kunmap_atomic(p, km);
-}
+#define put_aio_ring_event(event, km) do { \
+ struct io_event *__event = (event); \
+ (void)__event; \
+ kunmap_atomic((void *)((unsigned long)__event & PAGE_MASK), km); \
+} while(0)
/* ioctx_alloc
* Allocates and initializes an ioctx. Returns an ERR_PTR if it failed.
From: Benjamin LaHaise <[email protected]>
Date: Mon, 26 Aug 2002 17:53:22 -0400
Patrik Mochel noticed that fs/aio.c doesn't compile on a non-highmem config.
The patch below (and in the bk tree on master.kernel.org:/home/bcrl/aio-2.5)
fixes that by making the helper functions #defines, and should also be a
bit faster.
Platforms should fix this by making a dummy asm/kmap_types.h
Linus added the explicit include of asm/kmap_types.h and therefore
I believe this is how he wants this fixed too.
On Fri, 30 Aug 2002, David S. Miller wrote:
>
> Patrik Mochel noticed that fs/aio.c doesn't compile on a non-highmem config.
> The patch below (and in the bk tree on master.kernel.org:/home/bcrl/aio-2.5)
> fixes that by making the helper functions #defines, and should also be a
> bit faster.
>
> Platforms should fix this by making a dummy asm/kmap_types.h
>
> Linus added the explicit include of asm/kmap_types.h and therefore
> I believe this is how he wants this fixed too.
I don't really much care how it gets fixed, I could equally well imagine
having a dummy struct when CONFIG_HIGHMEM isn't set. Whatever makes the
dang thing work. There's certainly a good argument that non-broken
architectures shouldn't need to bother with kmap() at all..
Linus
From: Linus Torvalds <[email protected]>
Date: Fri, 30 Aug 2002 16:42:39 -0700 (PDT)
I don't really much care how it gets fixed, I could equally well imagine
having a dummy struct when CONFIG_HIGHMEM isn't set. Whatever makes the
dang thing work. There's certainly a good argument that non-broken
architectures shouldn't need to bother with kmap() at all..
Or that since the enumeration values are basically identical
on every system that the belong in linux/kmap_types.h :-)
On Fri, Aug 30, 2002 at 04:36:56PM -0700, David S. Miller wrote:
> Or that since the enumeration values are basically identical
> on every system that the belong in linux/kmap_types.h :-)
The main problem here is that one needs different kmap types depending
on which context a function is called from (which is why I needed the
enum as a parameter to the function). Unfortunately, the amount of
memory needed for ringbuffers can grow pretty large on a system with
many tasks, so not kmapping them isn't an option. Making it a #define
certainly works quite well, but if someone has a better idea to the
kmap mess, I'd love to see it improved.
-ben
--
"You will be reincarnated as a toad; and you will be much happier."