RE: Illegal use of reserved word in system.h

["Gilbert, John" <JGG@dolby.com>]

Richard B. Johnson writes:

The subject line is invalid. We don't make law here.
The correct word is invalid, not illegal. There should not be any
"illegal" strings in the kernel either although they sometimes creep
in...

#JG
Sorry, I was borrowing the term from the g++ error that this created.
I'm not trying to imply that someone should be arrested. ;^) Also, like
a few people have already mentioned, it doesn't effect the kernel at all
as it's strictly a C program.

Now, if you want the names of structure members changed, you are going
to have to submit a patch. You will also have to patch anything that
accesses those member names in user-mode.
Nobody is going to do it for you.
	
#JG
They are very trivial patches, but I'll include them here.

It's also quite presumptuous of you that you think that you can instruct
any of the kernel developers on how to write header files. In addition,
any user-mode code that uses kernel headers is broken by definition.
There is no other operating system except BSD that gives user mode code
access to kernel-headers. Somehow, people have been able to write
working code using those operating systems without using kernel headers.

#JG
Including header files might be bad practice, but it's not uncommon, and
only truly broken when the kernel changes. I know many reasons for why
it's bad, but I also know that it's sometimes necessary (see below).
It's also usually not my code that breaks, but I often have to fix it if
I want to get the program to work.

There are people who can instruct you in the proper methods of
interfacing with the kernel. There are even many books that have been
written. I suggest that if you have a driver that requires access to
kernel headers, when being accessed by user-mode code, the driver is
broken. Unix/linux provides standard methods of interface to drivers.
They include open(), close(), read(), write(), mmap() and ioctl(). In
addition, there are various semaphores and signaling mechanisms like
poll(). If you are accessing devices or kernel functions in other than
these standard interfaces, your code is broken beyond all repair.

#JG
As a counter-example, I'm including a program that uses /dev/dri to
framelock to vsync. It's stupid in multiple ways but it seems to be
currently the only semi-portable way to do this under X windows. It also
uses two kernel headers, and if you read through the code, it's spin
waiting for the ioctl call to return the right value, sometimes skipping
a frame. If you patch this into a C++ program with the stock kernel
headers, it breaks (the drm.h and drm_bufs.c patches fix this).
I'd really appreciate if some kernel developer enabled the "Correct" way
to do this. If there was a way to wake a thread (a blocking read on
/dev/vsync?) on a video vsync interrupt, a lot of media players, games,
and other real-time graphics dependant programs could take less system
resources, and have better quality graphics. In the meantime however,
this mostly works today (with patched kernel headers).


Also kernel headers don't show if the system the SQL code is running on
is SMP aware and Ray was much better behaved.

#JG
According to Adrian Bunk, MySQL is using inlines from asm/atomic.h (yes,
very bad). The fact they set CONFIG_SMP manually to expose some
additional code, but not setting the cpu count variables breaks builds
under later 2.6 kernels. See http://bugs.mysql.com/bug.php?id=10364
Again, it's not my code. Tweaking a few kernel headers is easier than
fixing everyone else's bad code practices.

John Gilbert




-----------------------------------------
This message (including any attachments) may contain confidential
information intended for a specific individual and purpose.  If you are not
the intended recipient, delete this message.  If you are not the intended
recipient, disclosing, copying, distributing, or taking any action based on
this message is strictly prohibited.

Attachment: patch.system.h
Description: patch.system.h

Attachment: patch.drm_bufs.c
Description: patch.drm_bufs.c

Attachment: patch.drm.h
Description: patch.drm.h

Attachment: vsync.h
Description: vsync.h

Attachment: vsync.c
Description: vsync.c