Messages in this thread | | | Date | Tue, 28 Jul 1998 21:19:29 +0200 (MET DST) | From | Emanuel Pirker <> | Subject | Developer questions (Modules, procfs, ...) |
| |
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
| |