Skip to contentSkip to conversation

: problem: pc_keyb.h

PATCH In review Nico Schottelius 2 participants 5 messages Aug 31, 2001 – Sep 5, 2001

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 : problem: pc_keyb.h

Hello Martin!

Why can't I include pc_keyb.h directtly into a C program ? I need that for a part of GPM.

nico@flapp:~/computer/programming/c/test > gcc pc_keyb.h.c In file included from pc_keyb.h.c:3:
/usr/include/linux/pc_keyb.h:127: parse error before `wait_queue_head_t'

/usr/include/linux/pc_keyb.h:127: warning: no semicolon at end of struct or union
/usr/include/linux/pc_keyb.h:130: parse error before `}'

When adding

#define wait_queue_head_t struct wait_queue *

(stolen from compatmac.h)

before including pc_keyb.h it runs fine.

So I suggest the following:

================================================
flapp:/usr/include/linux # diff -u compatmac.h.orig compatmac.h

-- compatmac.h.orig Fri Aug 31 13:14:38 2001

+++ compatmac.h Fri Aug 31 13:14:50 2001

@@ -151,7 +151,6 @@

#ifndef TWO_THREE

/* These are new in 2.3. The source now uses 2.3 syntax, and
here is

the compatibility define... */

-#define wait_queue_head_t struct wait_queue
*

#define DECLARE_MUTEX(name) struct semaphore name
= MUTEX

#define DECLARE_WAITQUEUE(wait, current) \

struct wait_queue wait = { current, NULL }

================================================
and

================================================
flapp:/usr/include/linux # diff -u pc_keyb.h.orig pc_keyb.h

pc_keyb.h Fri Aug 31 13:15:40 2001 renamed from pc_keyb.h.orig Fri Aug 31 13:15:31 2001 +0 -0
@@ -121,6 +121,8 @@
                                           but then the read function

would need
a lock etc - ick */

+#define wait_queue_head_t struct wait_queue *
+

 struct aux_queue {
        unsigned long head;
        unsigned long tail;

==================================================

Nico

#1 lore raw

Hello!

Quoted 2 lines

Why can't I include pc_keyb.h directtly into a C program ? I need that for a part of GPM.

pc_keyb.h is a kernel include, thus it uses the kernel set of types which unfortunately collides badly with the types used in user space.

The best solution is to create your own include and copy the relevant parts of pc_keyb.h there.

BTW what exactly do you plan to do? Sending keyboard controller or mouse controller commands from user space is probably very dangerous as it's going to collide with the commands sent by the kernel.

Have a nice fortnight

Signature · 3 lines
Martin `MJ' Mares   <[email protected]>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
If a train station is where the train stops, what is a work station?
#2 lore raw
In reply to Nico Schottelius

Hello Martin!

Quoted 5 lines
Quoted 2 lines

Why can't I include pc_keyb.h directtly into a C program ? I need that for a part of GPM.

pc_keyb.h is a kernel include, thus it uses the kernel set of types which unfortunately collides badly with the types used in user space.

Oh, didn't know that.

Quoted 2 lines

The best solution is to create your own include and copy the relevant parts of pc_keyb.h there.

hmm.. I just use some definations:

AUX_*

Quoted 4 lines

BTW what exactly do you plan to do? Sending keyboard controller or mouse controller commands from user space is probably very dangerous as it's going to collide with the commands sent by the kernel.

It's gpm what I am working on. I am the current maintainer. We get the mouse id.

Martin, can't you add the line I sent in the last mail ? This would make it possible to include pc_keyb.h into many programs directly.

Nico

#3 lore raw
In reply to Nico Schottelius

Hello!

Quoted 3 lines

Martin, can't you add the line I sent in the last mail ? This would make it possible to include pc_keyb.h into many programs directly.

Please don't do that, user space programs depending on a particular version of kernel headers have already created a horrible mess, so outside the cases where you need to share a definition of some kernel<->userspace interface, kernel headers really shouldn't be used outside the kernel.

Have a nice fortnight

Signature · 3 lines
Martin `MJ' Mares   <[email protected]>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Don't take life too seriously -- you'll never get out of it alive.
#4 lore raw
In reply to Nico Schottelius

okay, convinced.
It wasn't possible to use gpm with 2.0 kernels
anymore, if pc_keyb.h was included.
So i copied the relevant parts to our header file

This will appear in gpm-1.19.5.

Nico

Quoted 22 lines · Martin Mares

Hello!

Quoted 3 lines

Martin, can't you add the line I sent in the last mail ? This would make it possible to include pc_keyb.h into many programs directly.

Please don't do that, user space programs depending on a particular version of kernel headers have already created a horrible mess, so outside the cases where you need to share a definition of some kernel<->userspace interface, kernel headers really shouldn't be used outside the kernel.

Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Don't take life too seriously
-- you'll never get out of it alive.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/