linux-kernel - Re: Geode GX framebuffer driver: Arcom vs. AMD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 14 Jul 2007 16:57:11 -0400
From:	"Andrew Paprocki" <andrew@...iboo.com>
To:	"Sam Ravnborg" <sam@...nborg.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Geode GX framebuffer driver: Arcom vs. AMD

On 7/14/07, Sam Ravnborg <sam@...nborg.org> wrote:
> After a very brief look on the relevant part of the patch:
> -> Needs to be adapted to CodingStyle all over.

I agree, this can be done if it was ever going to be included.

> -> The use of AMD specific BUILDNUM etc are not used in-kernel

This can be cleaned up as well, or put behind some #ifdef to allow AMD
to keep using their own system, I suppose.

> -> The HAL in lib/cimarron needs to be justified - who are the oter users?

The HAL is used by the driver, obviously, but is included in
lib/cimarron for any other module writers which want to access the
graphics hardware from inside the kernel. When you're developing a
user app and want to access the hardware, you link Cimarron into your
code directly. I'm not sure what other kernel modules AMD expected to
be written, but I'm guessing they just wanted to keep their HAL and
write the framebuffer driver in terms of that instead of maintaining a
user-space HAL and a duplicate kernel driver.

> -> There seems to be a _lot_ of specific defines in lib/cimarron - I wonder
>    if this is the way used in the rest of the kernel?

Which defines are you referring to? I know there are a few 'settings'
which are modified by changing #defines in one of the .h files. I'm
assuming that those would be moved to Kconfig values if this was ever
in the kernel.

> But anyway - the patch it not trivially ready for inclusion.

I agree. I just did the work to port it from 2.6.11 to 2.6.22 just to
get it working in my tree. It all builds cleanly now, so any work
would most likely be cosmetic to clean up the code base.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/