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] [day] [month] [year] [list]
Date:	Tue, 12 Sep 2006 08:09:22 +0200
From:	"Miguel Ojeda" <maxextreme@...il.com>
To:	"Greg KH" <greg@...ah.com>
Cc:	akpm@...l.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.17.13] display: Driver ks0108 and cfag12864b

On 9/12/06, Greg KH <greg@...ah.com> wrote:
>
> The patch is linewrapped :(
>

Please tell me if the next one is linewrapped too.

>
> Why would you need to touch udev?  It will handle stuff loaded at any
> point in time automatically.  You don't have to "update udev" at all.
>

My fault. My firsts tests were on a Vector Linux, and, I don't know
why (bad cfg I guess), but udev didn't create the nodes automatically.
Now, in Debian, it does. I have noticed that and the last patch
doesn't have such lines. Sorry.

>
> Do you really mean for your header file to be under the GPL for
> userspace programs?
>

Ups, it is just an example for a user-space program that wants to use
the cfag12864b. I will remove the License line anyway.


>
> Which version of the GPL?
>

The same as the kernel, I think. Is that right?

> [about useless printk's]
> Is this really needed?
>

It isn't anymore. In the patch it is also removed and all the printks
improved, as Alexey Dobriyan told me also to do.

> "Display" is very generic, people will think it is for video stuff too.
> LCD perhaps might be better?
>

I thought the same, but LCD is already used by the "PDA Frontal LCD
Panel". They got the "linux/lcd.h" and "drivers/lcd/*", as well as a
fixed major number.

So I thought "bigger" and, IMHO a new folder for this kind of
misc-secondary-display devices (LCD or not) will be fine.

I think (maybe I'm wrong but...), we can just put the drivers right
there. There are a lot of this kind of hardware, but it will take time
to code more drivers. So if the resulting drivers are so different or
the drivers/* get a major update, relocate them. If not, leave them
until we have enough samples to start classifying.
-
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