RE: Preventing signal interrupt in Kernel module code

RE: Preventing signal interrupt in Kernel module code

[Kevin Curtis]

Thanks for the answer.  It was in the Linux Device Driver book too.  Should
have looked there first (this is available online at
http://www.xml.com/ldd/chapter/book/, very useful.

Just one more thing.  It would be nice to do something slightly different if
the signal was SIGTERM.  Is there anyway or seeing what signal caused the
interrupt?


Thanks again.

Kevin

-----Original Message-----
From: Quinn Harris [mailto:quinn@nmt.edu]
Sent: 13 September 2002 16:57
To: linux-newbie@vger.kernel.org
Subject: Re: Preventing signal interrupt in Kernel module code


Would placing the process waiting for the hardware in an
TASK_UNINTERRUPTIBLE state do what you want?  As far as I understand
it,  the TASK_UNINTERRUPTIBLE state is used to prevent anything from
waking up a process when it is waiting for something it can't be
interrupted by a signal from.  If you call wait_event(wq, condition);
(actually a define in sched.h) the process will be placed in a
TASK_UNINTERRUPTIBLE state until the wait queue is woken up and the
condition is met.  wait_event_interruptible(wq, condition) would allow a
process to be interrupted by a signal.  You might be doing essentially
what wait_event does without using it.  I have seen a bit of kernel code
(I think usually older code) that doesn't used wait_event when it could
to place the current process on a wait queue.


On Fri, 2002-09-13 at 07:54, Kevin Curtis wrote:
> Hi,
> 	I have written a Kernel module and I'm having a small problem with
> signals that I hope someone can steer me through.  The signal in question
> are SIGCHILD, but that is not really relevant.  I must be able to handle
any
> signal that the process has enabled.
> 
> 	My module has several wait queues, most of which I can cope with
> being interrupted by a signal (returning EINTR to the process).  However,
> there are some hardware operations that I need to wait for completion of,
as
> it would be impossible to restart them or pick up where we left off.  I
> still want to use a wait queue so other things can run.  Is there some
> system call I can make to mask signals until the operation has completed.
> Would I still call signal_pending() to see if one had occurred while they
> were blocked?
> 
> I'm sure the answer is really simple but I haven't stumbled across it yet.
> 
> TIA
> 
> Kevin
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs
> 


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

RE: Preventing signal interrupt in Kernel module code

[Quinn Harris]

It probably wouldn't be feasible to get a process to ignore every signal
except SIGTERM when its waiting on a queue.  But I am not sure, I would
need to look into it to get a good answer.

If you plan to do a bit of kernel development I would recommend spending
some time reading the kernel code.  This is an open source kernel and
accordingly, the answers to all these types of questions can be found in
the code.  The Linux Device Driver book is a good starting place (also
look at Understanding the Linux Kernel) but there is no substitute for
reading the code.  http://lxr.linux.no/ is a great tool for reading the
kernel.

I will say, it can be very daunting to make sense of the linux kernel
code at first.  Expect to spend many hours before you gain any real
understanding of how the pieces fit together.  Don't try to pick some
part of the kernel and read it line by line trying to understand it. 
This probably won't help much.  You might pick some general part of the
kernel to study that can stand somewhat alone like the virtual file
system or schedular.  Try to learn what the data structures represent
and what the various functions do.  Don't get caught up in exactly how
functions do what they do at first.

I feel that learning about the linux kernel improved my skills both with
the kernel and as a programmer.  It is good to see how other people
solve problems and generally the kernel has reasonably good solutions to
programming problems.


On Fri, 2002-09-13 at 09:49, Kevin Curtis wrote:
> Thanks for the answer.  It was in the Linux Device Driver book too.  Should
> have looked there first (this is available online at
> http://www.xml.com/ldd/chapter/book/, very useful.
> 
> Just one more thing.  It would be nice to do something slightly different if
> the signal was SIGTERM.  Is there anyway or seeing what signal caused the
> interrupt?
> 
> 
> Thanks again.
> 
> Kevin
> 
> -----Original Message-----
> From: Quinn Harris [mailto:quinn@nmt.edu]
> Sent: 13 September 2002 16:57
> To: linux-newbie@vger.kernel.org
> Subject: Re: Preventing signal interrupt in Kernel module code
> 
> 
> Would placing the process waiting for the hardware in an
> TASK_UNINTERRUPTIBLE state do what you want?  As far as I understand
> it,  the TASK_UNINTERRUPTIBLE state is used to prevent anything from
> waking up a process when it is waiting for something it can't be
> interrupted by a signal from.  If you call wait_event(wq, condition);
> (actually a define in sched.h) the process will be placed in a
> TASK_UNINTERRUPTIBLE state until the wait queue is woken up and the
> condition is met.  wait_event_interruptible(wq, condition) would allow a
> process to be interrupted by a signal.  You might be doing essentially
> what wait_event does without using it.  I have seen a bit of kernel code
> (I think usually older code) that doesn't used wait_event when it could
> to place the current process on a wait queue.
> 
> 
> On Fri, 2002-09-13 at 07:54, Kevin Curtis wrote:
> > Hi,
> > 	I have written a Kernel module and I'm having a small problem with
> > signals that I hope someone can steer me through.  The signal in question
> > are SIGCHILD, but that is not really relevant.  I must be able to handle
> any
> > signal that the process has enabled.
> > 
> > 	My module has several wait queues, most of which I can cope with
> > being interrupted by a signal (returning EINTR to the process).  However,
> > there are some hardware operations that I need to wait for completion of,
> as
> > it would be impossible to restart them or pick up where we left off.  I
> > still want to use a wait queue so other things can run.  Is there some
> > system call I can make to mask signals until the operation has completed.
> > Would I still call signal_pending() to see if one had occurred while they
> > were blocked?
> > 
> > I'm sure the answer is really simple but I haven't stumbled across it yet.
> > 
> > TIA
> > 
> > Kevin
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.linux-learn.org/faqs
> > 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs
> 


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

RE: Preventing signal interrupt in Kernel module code

[Ray Olszewski]

At 05:02 PM 9/13/02 +0100, Kevin Curtis wrote:
>Ok - I will refrain from posting technical questions here.  I did also post
>it to the linux-kernel mail list too.  It's just that sometimes, a question
>like mine is too trivial for them and gets ignored.  However, Ray is right,
>don't let postings like mine put you off sending in your questions too.
>
>By the way, even though I'm writing Kernel modules, I still have problems
>with my Mandrake distro too.  The latest being that sound has stopped
>working when I installed my network card.

Oh dear. I didn't mean to chastise you for your earlier posting. Especially 
since someone else did offer a suggestion about your problem. All I meant 
was what I actually said ... that your question was outside the range we 
typically deal with here. Please understand that I am no one special, just 
another member of the list. I wasn't trying to give people orders, just 
convey a sense of the list as it has operated historically.

As to your implied question ... when I experience similar problems, I 
usually find that they are pci bus problems, not Linux problems as such. 
(I've had both TV-tuner cards and NICs interfere with video cards, for 
example.) Observe during the early (pre-LILO or -GRUB or whatever you use) 
stages of the boot process to see if your BIOS still sees both the sound 
and NIC devices. If it doesn't, fiddle around ... try changing the slots of 
one of the other device (or just the NIC, if your mobo has on-board sound).

On the Linux end, see if the sound hardware still shows up in the 
"lspci"  listing. Check /proc/interrupts and /proc/ioports for a conflict 
(yes, I know Linux is supposed to share interrupts, but the reality is that 
it works imperfectly at best).

That's about all I can suggest without some details -- what sound card 
(what module), what NIC, and what "stopped working" means (what are you no 
longer able to do that you used to be able to do?).


--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski					-- Han Solo
Palo Alto, California, USA			  ray@comarre.com
-------------------------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

RE: Preventing signal interrupt in Kernel module code

[Kevin Curtis]

Ok - I will refrain from posting technical questions here.  I did also post
it to the linux-kernel mail list too.  It's just that sometimes, a question
like mine is too trivial for them and gets ignored.  However, Ray is right,
don't let postings like mine put you off sending in your questions too.

By the way, even though I'm writing Kernel modules, I still have problems
with my Mandrake distro too.  The latest being that sound has stopped
working when I installed my network card.


Kevin

-----Original Message-----
From: Ken Boyer [mailto:kboyer@logicalimages.com]
Sent: 13 September 2002 17:00
To: linux-newbie@vger.kernel.org
Subject: RE: Preventing signal interrupt in Kernel module code



Thank you for the clarification.

Ken


-----Original Message-----
From: linux-newbie-owner@vger.kernel.org
[mailto:linux-newbie-owner@vger.kernel.org] On Behalf Of Ray Olszewski
Sent: Friday, September 13, 2002 11:54 AM
To: Bill Pleasants; linux-newbie@vger.kernel.org
Subject: Re: Preventing signal interrupt in Kernel module code


At 11:33 AM 9/13/02 -0700, Bill Pleasants wrote:
>Hello,
>I was told this list was for beginners.  From what I have read in the 
>past week, I think I am out of place.  I just want help getting a 
>Mandrake installation to work. Yours truly,
>Bill


You were told right; this list is for beginners. Some of us who hang out

here are not beginners, though (how else would you get knowledgeable 
*answers*, after all?), and one of us may, from time to time, pose a 
somewhat more advanced question to his colleagues. Not all that often, 
though ... there are better places to get answers to advanced questions 
than here.

That said, we don't have any automated filter to keep really complex 
questions off the list, and from time to time, someone will post an 
extremely technical question here. The one you posted in response to is
a 
good example; I don't know if the poster will get any help here (he
might, 
though it is a long shot), but his question really is way above what we 
customarily discuss.

That said ... we answer questions here. You don't ask any in your
posting. 
If you are having trouble, you'll need to tell us what the trouble is.

Asking for help here is not a substitute for things like reading the 
documentation and following your distro's installations instructions --
we 
generally avoid the bluntness of "RTFM" and "STFW" replies, but we do 
retain the underlying expectation that for general questions, you will
turn 
to FAQs, man pages, and other general documentation. If this is what you

need to do, someone here will usually tell you so ... though a bit more 
politely than you might see elsewhere.

As to your questions ... we do assume that someone who wants help will
make 
the effort to describe what he has done, and the problems he has 
encountered, with some specificity. We don't try to write personalized, 
soup-to-nuts tutorials.

So with that as background, please do not hesitate to pose
beginner-level 
questions here.



--
-------------------------------------------"Never tell me the
odds!"--------
Ray Olszewski					-- Han Solo
Palo Alto, California, USA			  ray@comarre.com
------------------------------------------------------------------------
-------

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie"
in the body of a message to majordomo@vger.kernel.org More majordomo
info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Preventing signal interrupt in Kernel module code

[Kevin Curtis]

Hi,
	I have written a Kernel module and I'm having a small problem with
signals that I hope someone can steer me through.  The signal in question
are SIGCHILD, but that is not really relevant.  I must be able to handle any
signal that the process has enabled.

	My module has several wait queues, most of which I can cope with
being interrupted by a signal (returning EINTR to the process).  However,
there are some hardware operations that I need to wait for completion of, as
it would be impossible to restart them or pick up where we left off.  I
still want to use a wait queue so other things can run.  Is there some
system call I can make to mask signals until the operation has completed.
Would I still call signal_pending() to see if one had occurred while they
were blocked?

I'm sure the answer is really simple but I haven't stumbled across it yet.

TIA

Kevin
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Preventing signal interrupt in Kernel module code

[Kevin Curtis]

Hi,
	I have written a Kernel module and I'm having a small problem with
signals that I hope someone can steer me through.  The signal in question
are SIGCHILD, but that is not really relevant.  I must be able to handle any
signal that the process has enabled.

	My module has several wait queues, most of which I can cope with
being interrupted by a signal (returning EINTR to the process).  However,
there are some hardware operations that I need to wait for completion of, as
it would be impossible to restart them or pick up where we left off.  I
still want to use a wait queue so other things can run.  Is there some
system call I can make to mask signals until the operation has completed.
Would I still call signal_pending() to see if one had occurred while they
were blocked?

I'm sure the answer is really simple but I haven't stumbled across it yet.

TIA

Kevin

Re: Preventing signal interrupt in Kernel module code

[Quinn Harris]

Would placing the process waiting for the hardware in an
TASK_UNINTERRUPTIBLE state do what you want?  As far as I understand
it,  the TASK_UNINTERRUPTIBLE state is used to prevent anything from
waking up a process when it is waiting for something it can't be
interrupted by a signal from.  If you call wait_event(wq, condition);
(actually a define in sched.h) the process will be placed in a
TASK_UNINTERRUPTIBLE state until the wait queue is woken up and the
condition is met.  wait_event_interruptible(wq, condition) would allow a
process to be interrupted by a signal.  You might be doing essentially
what wait_event does without using it.  I have seen a bit of kernel code
(I think usually older code) that doesn't used wait_event when it could
to place the current process on a wait queue.


On Fri, 2002-09-13 at 07:54, Kevin Curtis wrote:
> Hi,
> 	I have written a Kernel module and I'm having a small problem with
> signals that I hope someone can steer me through.  The signal in question
> are SIGCHILD, but that is not really relevant.  I must be able to handle any
> signal that the process has enabled.
> 
> 	My module has several wait queues, most of which I can cope with
> being interrupted by a signal (returning EINTR to the process).  However,
> there are some hardware operations that I need to wait for completion of, as
> it would be impossible to restart them or pick up where we left off.  I
> still want to use a wait queue so other things can run.  Is there some
> system call I can make to mask signals until the operation has completed.
> Would I still call signal_pending() to see if one had occurred while they
> were blocked?
> 
> I'm sure the answer is really simple but I haven't stumbled across it yet.
> 
> TIA
> 
> Kevin
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs
> 


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Preventing signal interrupt in Kernel module code

[Bill Pleasants]

Hello,
I was told this list was for beginners.  From what I have read in the
past week, I think I am out of place.  I just want help getting a
Mandrake installation to work.
Yours truly,
Bill

        linux-newbie@vger.kernel.org, linux-kernel@vger.kernel.org
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

RE: Preventing signal interrupt in Kernel module code

[Ken Boyer]

And I thought it was just me...

Are there any other Linux lists that are more of a beginner level? 

Ken


-----Original Message-----
From: linux-newbie-owner@vger.kernel.org
[mailto:linux-newbie-owner@vger.kernel.org] On Behalf Of Bill Pleasants
Sent: Friday, September 13, 2002 2:34 PM
To: linux-newbie@vger.kernel.org
Subject: Re: Preventing signal interrupt in Kernel module code


Hello,
I was told this list was for beginners.  From what I have read in the
past week, I think I am out of place.  I just want help getting a
Mandrake installation to work. Yours truly, Bill

        linux-newbie@vger.kernel.org, linux-kernel@vger.kernel.org
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie"
in the body of a message to majordomo@vger.kernel.org More majordomo
info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Preventing signal interrupt in Kernel module code

[Ray Olszewski]

At 11:33 AM 9/13/02 -0700, Bill Pleasants wrote:
>Hello,
>I was told this list was for beginners.  From what I have read in the
>past week, I think I am out of place.  I just want help getting a
>Mandrake installation to work.
>Yours truly,
>Bill


You were told right; this list is for beginners. Some of us who hang out 
here are not beginners, though (how else would you get knowledgeable 
*answers*, after all?), and one of us may, from time to time, pose a 
somewhat more advanced question to his colleagues. Not all that often, 
though ... there are better places to get answers to advanced questions 
than here.

That said, we don't have any automated filter to keep really complex 
questions off the list, and from time to time, someone will post an 
extremely technical question here. The one you posted in response to is a 
good example; I don't know if the poster will get any help here (he might, 
though it is a long shot), but his question really is way above what we 
customarily discuss.

That said ... we answer questions here. You don't ask any in your posting. 
If you are having trouble, you'll need to tell us what the trouble is.

Asking for help here is not a substitute for things like reading the 
documentation and following your distro's installations instructions -- we 
generally avoid the bluntness of "RTFM" and "STFW" replies, but we do 
retain the underlying expectation that for general questions, you will turn 
to FAQs, man pages, and other general documentation. If this is what you 
need to do, someone here will usually tell you so ... though a bit more 
politely than you might see elsewhere.

As to your questions ... we do assume that someone who wants help will make 
the effort to describe what he has done, and the problems he has 
encountered, with some specificity. We don't try to write personalized, 
soup-to-nuts tutorials.

So with that as background, please do not hesitate to pose beginner-level 
questions here.



--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski					-- Han Solo
Palo Alto, California, USA			  ray@comarre.com
-------------------------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

RE: Preventing signal interrupt in Kernel module code

[Ken Boyer]

Thank you for the clarification.

Ken


-----Original Message-----
From: linux-newbie-owner@vger.kernel.org
[mailto:linux-newbie-owner@vger.kernel.org] On Behalf Of Ray Olszewski
Sent: Friday, September 13, 2002 11:54 AM
To: Bill Pleasants; linux-newbie@vger.kernel.org
Subject: Re: Preventing signal interrupt in Kernel module code


At 11:33 AM 9/13/02 -0700, Bill Pleasants wrote:
>Hello,
>I was told this list was for beginners.  From what I have read in the 
>past week, I think I am out of place.  I just want help getting a 
>Mandrake installation to work. Yours truly,
>Bill


You were told right; this list is for beginners. Some of us who hang out

here are not beginners, though (how else would you get knowledgeable 
*answers*, after all?), and one of us may, from time to time, pose a 
somewhat more advanced question to his colleagues. Not all that often, 
though ... there are better places to get answers to advanced questions 
than here.

That said, we don't have any automated filter to keep really complex 
questions off the list, and from time to time, someone will post an 
extremely technical question here. The one you posted in response to is
a 
good example; I don't know if the poster will get any help here (he
might, 
though it is a long shot), but his question really is way above what we 
customarily discuss.

That said ... we answer questions here. You don't ask any in your
posting. 
If you are having trouble, you'll need to tell us what the trouble is.

Asking for help here is not a substitute for things like reading the 
documentation and following your distro's installations instructions --
we 
generally avoid the bluntness of "RTFM" and "STFW" replies, but we do 
retain the underlying expectation that for general questions, you will
turn 
to FAQs, man pages, and other general documentation. If this is what you

need to do, someone here will usually tell you so ... though a bit more 
politely than you might see elsewhere.

As to your questions ... we do assume that someone who wants help will
make 
the effort to describe what he has done, and the problems he has 
encountered, with some specificity. We don't try to write personalized, 
soup-to-nuts tutorials.

So with that as background, please do not hesitate to pose
beginner-level 
questions here.



--
-------------------------------------------"Never tell me the
odds!"--------
Ray Olszewski					-- Han Solo
Palo Alto, California, USA			  ray@comarre.com
------------------------------------------------------------------------
-------

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie"
in the body of a message to majordomo@vger.kernel.org More majordomo
info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Preventing signal interrupt in Kernel module code

[Bryan Whitehead]

Bill Pleasants wrote:
> Hello,
> I was told this list was for beginners.  From what I have read in the
> past week, I think I am out of place.  I just want help getting a
> Mandrake installation to work.
> Yours truly,
> Bill
> 
>         linux-newbie@vger.kernel.org, linux-kernel@vger.kernel.org
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs

Mandrake has a "newbie" list you might want to check out.

http://www.mandrakelinux.com/en/flists.php3

-- 
Bryan Whitehead
SysAdmin - JPL - Interferometry Systems and Technology
Phone: 818 354 2903
driver@jpl.nasa.gov

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs