linux-kernel - Re: 2.6.19-rc1-mm1

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:	Tue, 10 Oct 2006 01:10:52 -0700
From:	Andrew Morton <akpm@...l.org>
To:	"Miguel Ojeda" <maxextreme@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: 2.6.19-rc1-mm1

On Tue, 10 Oct 2006 07:31:23 +0000
"Miguel Ojeda" <maxextreme@...il.com> wrote:

> On 10/10/06, Andrew Morton <akpm@...l.org> wrote:
> >
> > +# drivers-add-lcd-support.patch: Pavel says use fbcon
> > +drivers-add-lcd-support.patch
> > +drivers-add-lcd-support-update.patch
> >
> 
> Has the # a special meaning?

It's a comment separator ;)

> I'm going to work on offering the fbcon feature as Pavel requested.

Thanks.  It does sound like making the thing an fbdev is the right way to go.

> suggested 2 ways.
> 
> Pavel's idea: Change the driver so the cfag12864b module will be just
> a framebuffer device, removing access through /dev/cfag12864b.
> 
> My idea: Code a new module called "fbcfag12864b", which will depend on
> cfag12864b and will be the framebuffer device. This way we have both
> devices, and they doesn't affect each other as they are different
> things. So the ks0108 and cfag12864b can stay without any changes.
> Also, if we finally decide we don't want the raw cfag12864b module, it
> is easy to remove it from the cfag12864b and the fbcafg12864b will
> continue working.
> 
> Is there anyone who can decide which idea is better? If not, I will
> code it my way. Also, if the Pavel's idea will be the chosen one, it
> will be easier to put the fbcfag12864b code into the cfag12864b rather
> than the opposite.

I'd have thought that once the device is accessible as an fbdev, there's so
much other software and kernel infrastructure to support that, there's
little point in offering an alternative way of presenting the device to
userspace.
-
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/