Developer questions (Modules, procfs, ...)

Emanuel Pirker (epirker@edu.uni-klu.ac.at)
Tue, 28 Jul 1998 21:19:29 +0200 (MET DST)


Hi there,

my name is Emanuel Pirker and I am the primary developer of the Linux
IEEE-1394 (FireWire) subsystem. For those of you who don't know,
FireWire is a high-speed, but low-cost serial bus standard to connect
digital multimedia equipment as well as mass storage devices to PCs.

I have several kernel-related questions and I hope that some of you can
help me or point out sources of good documentation.

a) Modularizing. I have a core module. "Below" this module are the
host-adapter-dependent modules (e.g. TI, Adaptec, OHCI drivers), "above"
are the device-dependend modules (e.g. mass storage device, camcorder).

The core module exports function which are called by the other modules.
But how should I handle the case of "the core modules calls functions of
other modules"? I copied most stuff from the SCSI subsystem and it works,
_but_:
* I don't know how it works and this _annoys_ me
* I have to recompile the whole kernel, not just the modules when
updating a non-firewire-kernel
* I have some problems, e.g. sometimes functions are called that
shouldn't be called. Obviously a function pointer problem, but
how should I debug a system I don't understand?

So my question:
Is there a better way than the SCSI subsystem's approach?
If yes, where do I find docs about it.
If no, where do I find an explanation about it.

b) Naming. The official IEEE term is "Serial Bus" (capitalized), the
standard is called IEEE Std 1394-1995. Everyone knows the technology
under the name "FireWire" which is a trademark of Apple Computer, Inc.
IEEE1394 or IEEE-1394 is the spelling for those who want to avoid problems
and I think we should too. I would prefer to name kernel constants and
data structures which are "known" outside the subsystem (e.g. configuration
defines, procfs inode constants, etc.) with IEEE1394. But what about
/proc/ieee1394? Should this be called /proc/firewire?

c) procfs interface. It's same case as above. I took some code of the
SCSI subsystem because it's overall structure is similar. But
now I am not content any more.

I want to have a subdir /proc/ieee1394. The core modules assigns a file
ieee1394 where some useful information about loaded modules,
detected host adapters and detected bus devices is given. Every class
of host adapters gets a subdirectory, where files 0, 1, 2 etc. are
given - each for one installed host adapter. Same as in the SCSI subsystem.

When looking at recent kernel sources, I noticed that there are now much
more subdirs than just net/ and scsi/. Which of those new things (e.g. pci)
should I use as an example or template? Where is a detailed doc on this?
Is the structure I described above, basically ok? If yes, can I already
allocate a PROC_IEEE1394 root inode number?

d) What driver is a good example for usage of /proc/sys?

To avoid misunderstanding: I am not afraid of reading sources and hacking.
Basically, this is what I did with this kernel-related parts so far. But
as the subsystem is getting more mature I don't want to have code parts in
it which are just "hacked" and not the result of sophisticated programming.
(yes, I'm studying CS and I believe my software engineering professors :-))

Thanks for your help,

Emanuel

BTW: If you are interested in the Linux IEEE-1394 project, look at
http://www.edu.uni-klu.ac.at/~epirker/ieee1394/

---------------------------------------------------------------------------
Emanuel Pirker
epirker@edu.uni-klu.ac.at E.Pirker@FH-Kaernten.ac.at

-
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.altern.org/andrebalsa/doc/lkml-faq.html