linux-kernel - RE: [PATCH][RFC] Remove support for the orphaned, obsolete Digi EPCA driver.

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: <335DD0B75189FB428E5C32680089FB9F012DD309@mtk-sms-mail01.digi.com>
Date:	Mon, 2 Jul 2007 09:56:50 -0500
From:	"Kilau, Scott" <Scott_Kilau@...i.com>
To:	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	"Robert P. J. Day" <rpjday@...dspring.com>
Cc:	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Eng.Linux" <Eng.Linux@...i.com>
Subject: RE: [PATCH][RFC] Remove support for the orphaned, obsolete Digi EPCA driver.

Hi all,

> Last time I poked at the tools they were working under 2.6 with some
> trivial compile fixes. Ideally this driver would be trimmed 
> to ISA only
> and the newer dgrs drivers merged but latter half appears to 
> be something
> digi have no interest in

I would be very surprised if anyone uses/could use the existing "epca"
drivers in the kernel.

As Robert has noticed, they would *not* work out-of-the-box, and would
require tweaking in the userspace utils as well as the kernel code as
well.

We here at Digi would love to see the "epca" driver go away from the
kernel sources and replace it with our new "dgap" open source driver,
but I can understand where you are coming from Alan.

As for merging the new Digi driver (dgap) source code that actually
work under 2.6 kernel, I attempted that a few years ago...

It did not go well, which I know and understand is expected for
merging ANY new driver into the kernel.

However, it was discovered during that time, there are
fundamental things/changes required to the driver that would 
end up crippling our driver in the "usability" department.

(Probably the biggest obstacle, was the extra ioctls to
manage "Digi" specific things, and other hooks that are
simply not permitted in in-kernel code)

Trust me, I *know* the pain of keeping the driver out-of-tree
with the constant flux in the kernel API, and I understand that
most people here say its completely self-inflicted...

But massively crippling the driver from a usability POV,
just simply isn't an option.

Thus, I have to keep the driver, open source, but out-of-tree,
and take the lumps of the constantly changing kernel API as
they are dished out.

Scott Kilau
Digi International
-
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/