linux-kernel - Re: [PATCH] fb/intelfb: Do not depend on EMBEDDED

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:	Mon, 14 Dec 2009 10:36:14 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Jean Delvare <jdelvare@...e.de>
Cc:	Dave Airlie <airlied@...ux.ie>, Jeff Mahoney <jeffm@...e.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fb/intelfb: Do not depend on EMBEDDED

On Sun, 13 Dec 2009 12:50:13 +0100
Jean Delvare <jdelvare@...e.de> wrote:
> Le samedi 12 décembre 2009 22:55, Jesse Barnes a écrit :
> > Right, the logic is that the driver really is for embedded (i.e.
> > very special purpose) use.  It should not be selected unless you
> > really know what you're doing or are building a very particular
> > product.   
> 
> The Kconfig help text doesn't say anything about this.
> 
> My understanding is that the intelfb driver was not _designed_ to be
> useful on embedded designs only. It just happens to be incomplete in
> such a way that it works only in a few selected cases, which happen
> to be embedded cases, and it fails in many other cases.
> 
> The proper way to handle this is not to make the driver depend on
> EMBEDDED. The proper way would be to change the intelfb driver so
> that it no longer binds to devices it will not properly support. If
> the driver doesn't support LVDS (whatever it is) then it should
> cleanly fail on systems which have that.

Sorry my last message came across as a bit curt (I was writing on a
phone and didn't want to type anymore :).

Making intelfb not bind to unsupported devices would require a good
chunk of work; it would need to scan available outputs among other
things.

> The reason why I sent a patch in the first place is exactly opposite:
> I want to let distros select this driver. My case is as follows: we
> had a product which included the intelfb driver, which we are in the
> process of upgrading. Now we find that the intelfb driver is gone
> (no longer selectable), which causes a problem as far as the upgrade
> path of our customers is concerned.

Hopefully you can migrate your product to the KMS based fb driver
instead.  It should provide the same functionality but with a better
feature set (e.g. suspend/resume support).

> So the problem I have to solve is: given a customer who was
> successfully using the intelfb driver before, what solutions can we
> offer when said customer upgrades to our new product? My own solution
> was straightforward: keep including the intelfb driver in the new
> product. Thus my patch dropping the dependency on EMBEDDED. If
> another solution exists, please let me know.

Enabling EMBEDDED for your distro would be another option; if you have
a very specific product in mind and want to preserve the same features
and bugs, then that might be the best route in this particular case.

> It would help if the DRM option description was updated. It still
> reads: "Direct Rendering Manager (XFree86 4.1.0 and higher DRI
> support)". If the DRM core is now also providing support for
> framebuffer-like functionality (again, if I understand correctly)
> then the reference to XFree86 should be dropped. The help text
> should also be updated to properly describe all that the DRM core
> offers today.

Yeah, we do need better help text.  People still get confused about
i830 and i810 as well...

-- 
Jesse Barnes, Intel Open Source Technology Center
--
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/