linux-kernel - Re: [PATCH] Add the ability to layer another driver over the serial 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]

Date:	Wed, 13 Dec 2006 01:21:32 +0100
From:	Tilman Schmidt <tilman@...p.cc>
To:	Alan <alan@...rguk.ukuu.org.uk>
CC:	Corey Minyard <cminyard@...sta.com>,
	Guennadi Liakhovetski <g.liakhovetski@....de>,
	linux-serial@...r.kernel.org,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Hansjoerg Lipp <hjlipp@....de>, Russell Doty <rdoty@...hat.com>
Subject: Re: [PATCH] Add the ability to layer another driver over the serial
 driver

Am 11.12.2006 18:40 schrieb Alan:
> On Mon, 11 Dec 2006 17:58:29 +0100
> Tilman Schmidt <tilman@...p.cc> wrote:
> 
>> On Mon, 11 Dec 2006 10:20:16 +0000, Alan wrote:
>>> This looks wrong. You already have a kernel interface to serial drivers.
>>> It is called a line discipline. We use it for ppp, we use it for slip, we
>>> use it for a few other things such as attaching sync drivers to some
>>> devices.
>> I was under the impression that line disciplines need a user space
>> process to open the serial device and push them onto it. 
> 
> Yes that is correct. You need a way for the user to tell you which port
> to use and to the permission and usage management for it anyway (as well
> as load the module and configure settings), so this seems quite
> reasonable.

I'm afraid I'm not familiar with Linux' SLIP implementation.
So there's a line discipline called "slip" which, when pushed
onto a serial port, registers as a network device, right? How
does it get - and stay - pushed? Is there a daemon process which
opens the serial port, pushes the line discipline onto it, and
then just sleeps, keeping the serial port open so that the line
discipline stays put? Can you point me to the source for such a
daemon for reference?

What I am actually looking for is a way to port an existing driver
which directly programs an i8250 serial port, to cooperate more
cleanly with the existing serial port drivers of Linux (and, at
the same time, shed the dependency on the specific serial port
hardware.) If that requires a permanently running (or sleeping)
userspace daemon, then so be it. (Although I admit I'd rather do
without.)

Thanks
Tilman

-- 
Tilman Schmidt                          E-Mail: tilman@...p.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

Download attachment "signature.asc" of type "application/pgp-signature" (254 bytes)