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, 05 Jun 2007 23:41:50 +0200
From:	Tilman Schmidt <tilman@...p.cc>
To:	"Lars K.W. Gohlke" <lkwg82@....de>
CC:	huang ying <huang.ying.caritas@...il.com>,
	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	linux-kernel@...r.kernel.org
Subject: Re: How to access correctly serial port inside module?

Am 03.06.2007 22:28 schrieb Lars K.W. Gohlke:
> Tilman Schmidt schrieb:
>> Am 17.05.2007 08:15 schrieb huang ying:
>>> I think the "serio" (through drivers/input/serio/serport.c) may be a
>>> choice too, like that in linux/drivers/input/mouse/sermouse.c, which
>>> is an example to program serial port in kernel space.
>> Interesting. I wonder if that would have been a better choice for
>> the Gigaset M101 driver. It seems even to have a probe mechanism
>> so one could try to determine if the expected device is really
>> connected to the port.
> 
>> Is there any documentation on this interface? I find the source a
>> bit hard to understand, sparsely commented as it is.
> 
> how can I open ttyS1 with major=4 and minor=65?

a) With "my" approach, ie. writing a line discipline, you open
/dev/ttyS1 in a user space program and then push your line discipline
onto it using ioctl(,TIOCSETD,).

b) With the "serio" approach, if the probe mechanism is really what
I think it is, you register your probe function and wait for it to
be called for each active serial port, then do your thing to determine
whether this is a/the port you want to use.

> Does anybody have some code to read from it the first e.g. 2bytes?

That's not how things work in the kernel. You don't "read the first
<n> bytes" at will. You have to provide means to process whatever
data happens to arrive on the serial port, as it arrives.

a) With a line discipline, you provide a callback function
".receive_buf" which will be called by the serial driver if some
data has been received, and has to process that data then and there.
You might just stow it away in a buffer of course, provided you
are sure to get around to processing it later.

b) With the "serio" interface, it seems the ".interrupt" function
serves the same purpose - though, as I said, I am not really
competent on that topic.

HTH
T.

-- 
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ