Re: serial.c

From: Rich Bryant (rfb6435@osfmail.isc.rit.edu)
Date: Wed May 10 2000 - 17:35:00 EST


Thanks for the response(Both Ted and Steve) I agree that changing the
kernel isn't something easy and I am being asked to make or atleast look
into some very major changes in order to fit a linux system into a very
small system. I appoligize if I am over generalizing or acting like I want
everything in life to be easy.

My main frustration that I have with the Kernel is that it is hard to
get a grasp on where things are defined. I see a function call that has no
description, and doesn't even have a reference to what file it is in. I
then have to grep through directories looking for it.

The fact that the drivers support multiple devices also makes it hard
to know what I need and what I don't. The goal of my whole project is to
create a version of Linux(preferebly Real Time) for an embedded board. The
board is for educational use and the way the Kernel is organized is very
forbidding to someone who only wants to look at specific areas and
understand them. The fact that the board has limited hardware makes it an
even greater challenge. I have no need for the majority of the drivers and
in many cases large portions of the drivers I do need.

I do have the specification for the 16550, understanding the hardware isn't
any where near as confusing as tryign to figure out what I can safely
eliminate from the driver and what is used by other functions within it. I
don't mind spending a couple weeks to understand the driver, but I find
myself digging through files for something that could have been stated in a
3 word comment.

I do notice that the comments have gotten better with newer versions of
Kernel, but there is also more complexity with the addition of new things
to the Kernel. Has there been any thought given to other ways of
supporting devices rather than numberous #ifndef statements?

Forgive me for ranting,

Rich

Wed, 10 May 2000, Theodore Y. Ts'o wrote:

>
> Steve pretty much covered most of responses I would have given, so I'll
> limit myself to pointing out a couple of other resources.
>
> 1) If you're trying to write Linux device driver for a non-16550
> device, check out the definitions in include/linux/tty_driver.h and
> include/linux/tty_ldisc.h. That documents most of the Linux tty
> interfaces, at least at a basic level.
>
> 2) If you're trying to figure out how to program a 16550 UART for the
> purposes of creating a device driver for another OS, I suggest you get a
> copy of the National Semincoductor Application Notes for the 16550 UART.
> They have some very nicely documented code which shows how to access the
> UART. Another good reference guide is the book "Programmer's Technical
> Reference: Data and Fax Communications", by Robert L. Hummet, which has
> a good section on explaining UART programming.
>
> - Ted
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:16 EST