On Sun, 27 Dec 1998, Juergen Braukmann wrote:
> Tomi Manninen wrote:
> > On Wed, 23 Dec 1998, Affan Basalamah wrote:
> >
> > > kissattach : TIOCSETD : invalid argument
> >
> > No MKISS support in the kernel or mkiss.o module not loaded.
>
> I always thought, that kerneld would "miracusly" load the modul I want,
> without me careing about. My question is a bit off topic, since I'd like
> to know what causes kerneld to load a module, or why my ax25 or mkiss
> module was not -as expected- loaded.
MKISS as seen by the kernel is a so called serial line discipline, a
method to communicate using a serial connection. SLIP and PPP are
other examples of line disciplines.
What happens is that kissattach tries to set the line discipline of the
serial port you have chosen to MKISS. It is first setting a variable disc
to N_AX25 (a macro defined in /usr/include/asm/termios.h to be 5) and
after that it uses the system call ioctl() with that and TIOCSETD
(TeleTYpewriter IO Control SET line Discipline) as arguments. And that
system call is what fails as the kernel is not able to fullfill the
request.
Now, what the kernel does before giving up is that it first looks if the
wanted line discipline is already registered by some driver or module (it
might be statically compiled in the kernel or the module providing it
might already be loaded). If it isn't registered the kernel has no
knowledge of what that line discipline is and what it does. All it can do
is to make a request for kerneld to load "tty-ldisc-5". It's then up to
you to teach kerneld what module provides that line discipline. So you put
this in your /etc/conf.modules:
alias tty-ldisc-5 mkiss
and suddenly it all just works!
The same thing works for other things, for example network protocol
families. If someone tries to make an AX.25 connection, the kernel tries
to load net-pf-3 (PF_AX25 is defined in /usr/include/linux/socket.h to be
3). When I touch any of the sound related device special files in /dev the
kernel tries to load char-major-14 (because they are character special
files with major number 14, see ls -l /dev/audio for example).
Also when I initialize my network card, my kernel tries to load module
eth0. This time it's named after the interface but I still have to tell
kerneld that I have an old WD8003 card so I put "alias eth0 wd" to
/etc/conf.modules.
All in all the thing that triggers the loading of a module, and the name
by which the module is tried to be loaded varies. Fortunately with a
reasonable setup, the failed attempt is logged to syslog. You probably
have lots of "failed to locate module tty-ldisc-5" messages in your
/var/log/message file.
This all can seem pretty confusing but it really is just about the only
way a powerfull and flexible module loading system like this can work. The
best thing about this is all is that when someone writes a device driver
for some exotic gizmo, no-one needs to make the kernel specifically aware
of this new driver. All one needs is to pick a unique major number for it
and write a module and possibly write some user space utilities like our
ax25-utils that use that number to request services from the kernel. Later
of course this unique number should be registered and included in kernel
and/or libc headers. Same goes for a new protocol family or a new line
discipline.
--
--... Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ...--
