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: <46556E3A.5090005@gmx.de>
Date:	Thu, 24 May 2007 12:51:38 +0200
From:	"Lars K.W. Gohlke" <lkwg82@....de>
To:	Tilman Schmidt <tilman@...p.cc>
CC:	linux-kernel@...r.kernel.org
Subject: Re: How to access correctly serial port inside module?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tilman Schmidt schrieb:
> Am 14.05.2007 15:00 schrieb Lars K.W. Gohlke:
>> after searching the mailing list and searching the web, I still don't
>> know how to access correctly the serial port (in user space known as
>> /dev/ttyS01)
>
> I can only tell you how I did it in the special case of the
> ser_gigaset driver which drives an ISDN device attached to
> a serial port: I implemented it as a line discipline which
> is associated to the appropriate serial port by a userspace
> daemon.
>
> Reading material:
>
> Documentation/tty.txt
> 	documentation on the line discipline interface
> include/linux/tty.h
> include/linux/tty_ldisc.h
> 	definitions for same
> drivers/isdn/gigaset/ser-gigaset.c
> 	my code - a simple example of abusing the line
> 	discipline interface for your own ends :-)
>
>> would somebody be so kind to give me an example:
>
> I hope the following will help you some. If not, feel free to
> ask again.
>
>> with this behaviour:
>>
>> 1. read from port
>
> That's not how things work in the kernel. There is no system
> call for reading some data that has arrived on that port or
> blocking if there is none, like a userspace program would do.
> Instead, when you register your line discipline you provide
> a callback function (receive_buf) for the serial driver to
> call when data has been received. That function can be called
> at any time and has to deal with the data as it gets it.
>
>> 2. output via printk()
>
> You can of course put a printk() in your receive_buf function.
> But ultimately you'll want to do more than that with the data,
> I'm sure.
>
>> 3. write to port
>
> That's easy. :-) No, it isn't. The serial driver *does*
> provide a function (aptly called "write") for sending data
> to the serial port, but you can't just call it any time you
> like. You have to synchronize with the driver by waiting for
> it to call your "write_wakeup" callback before you can call
> its write function again.
>
> HTH
> T.
>

I read you piece of code but it is overkill for me, I dont not see the
wood for the trees.

Many lines I'm recognizing as things I have read about kernel in my
book, but far away from understanding.

Anyway thx.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959

iD8DBQFGVW47AAomYJ1taN8RAuccAJ9TIvocrrVFCwcxnFsZZo8cLxLgKACglwD3
/zudmDgwvWo/5St0zC0UnHI=
=1Qgs
-----END PGP SIGNATURE-----

View attachment "lkwg82.vcf" of type "text/x-vcard" (125 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ