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]
Message-ID: <76366b180707141357g39eca7a8p706f39a7a515719a@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ