Network modules

[InuY4sha]

Hi, I'm trying to document myself about how kernel handles network
modules for interfacing with the userspace and drivers.
I got almost everything like
lsmod module --> init
ifconfig up --> open
ifconfig down --> close

what I don't get is WHAT exactly triggers the hard_start_xmit function
of the net_device structure...
I'm guessing that just having some data in the sk_buff data structure
while the queue is awake will trigger the function... am I wrong ?

Thanks in advance,
R

 

[Antoninus Twink]

what I don't get is WHAT exactly triggers the hard_start_xmit function
of the net_device structure...
I'm guessing that just having some data in the sk_buff data structure
while the queue is awake will trigger the function... am I wrong ?

Things start off in the higher layers: some higher-level protocol wants
to send a packet over a network device, so it creates a socket buffer
and passes this to the dev_queue_xmit function.

If the network device doesn't have a queue (e.g. it's a virtual device),
then dev_queue_xmit will call hard_start_xmit directly.

More usually, dev_queue_xmit will add the socket buffer to the output
queue of the network device, and then call qdisc_run to start processing
the queue. This function works through the queue, sending each packet in
turn using hard_start_xmit, until there are no more packets on the
queue, or until the device stops accepting packets. In the second case,
the socket buffer is put back onto the queue and a NET_TX_SOFTIRQ
interrupt is raised.

 

[InuY4sha]

Antoninus Twink ha scritto:

Things start off in the higher layers: some higher-level protocol wants
to send a packet over a network device, so it creates a socket buffer
and passes this to the dev_queue_xmit function.
If the network device doesn't have a queue (e.g. it's a virtual device),
then dev_queue_xmit will call hard_start_xmit directly.

More usually, dev_queue_xmit will add the socket buffer to the output
queue of the network device, and then call qdisc_run to start processing
the queue.
This function works through the queue, sending each packet in
turn using hard_start_xmit, until there are no more packets on the
queue, or until the device stops accepting packets.In the second case,
the socket buffer is put back onto the queue and a NET_TX_SOFTIRQ
interrupt is raised.

Probably this is a critical point to me. Let me try to explain: when I
use the line
dev->open = mydev_open;
I know that the ifconfig shall open the device calling that function;
in my code I don't have any dev_queue_xmit; I just have the definition
of
dev->hard_start_xmit= mydev_xmit;
And I don't get how the glue with its trigger is created. I know that
the tx function has the following interface:
static int mydev_xmit(struct sk_buff *skb,struct net_device *dev);
I suppose that in my case the interface has a queue, as I use a
sk_buff structure. What I understood from your post is that the
"output queue of the network device" is not cyclically checked by the
kernel that eventually triggers the hard_start_xmit.
Instead, it's for instance a socket in userspace that calls the
dev_queue_xmit() (through a send() function for instance) which passes
the data to network interface and triggers the hard_start_xmit
function...
This doesn't make much sense to me as I don't get then how the
dev_queue_xmit can know about the registered net_device to use in the
kernel module...

Sorry for asking again but can you try to explain a bit more with such
a newbie ?
Thanks,
R

 

[Antoninus Twink]

In my code I don't have any dev_queue_xmit; I just have the definition
of
dev->hard_start_xmit= mydev_xmit;
And I don't get how the glue with its trigger is created. I know that
the tx function has the following interface:
static int mydev_xmit(struct sk_buff *skb,struct net_device *dev);
I suppose that in my case the interface has a queue, as I use a
sk_buff structure. What I understood from your post is that the
"output queue of the network device" is not cyclically checked by the
kernel that eventually triggers the hard_start_xmit.
Instead, it's for instance a socket in userspace that calls the
dev_queue_xmit() (through a send() function for instance) which passes
the data to network interface and triggers the hard_start_xmit
function...
This doesn't make much sense to me as I don't get then how the
dev_queue_xmit can know about the registered net_device to use in the
kernel module...

dev_queue_xmit receives a pointer to an sk_buff structure as an
argument. This contains all the information needed. For example,
skb->dev is the outgoing device, and skb->data points to the beginning
of the payload, which has length skb->len.

On the question of queuing, you can tell just from the sk_buff structure
whether the device in question supports a queue, by examining the
skb->dev->enqueue field. Most physical devices will have a queue, while
virtual devices (e.g. the loopback device) generally won't.

 

[Keith Thompson]

Hi, I'm trying to document myself about how kernel handles network
modules for interfacing with the userspace and drivers.
I got almost everything like
lsmod module --> init
ifconfig up --> open
ifconfig down --> close

what I don't get is WHAT exactly triggers the hard_start_xmit function
of the net_device structure...
I'm guessing that just having some data in the sk_buff data structure
while the queue is awake will trigger the function... am I wrong ?

Your question isn't about the C language, which is what we discuss
here. Assuming the kernel in question is Linux, you should ask in one
of the Linux newsgroups (possibly linux.dev.kernel, but check the
newsgroup first; all I know about it is that it exists).

 

[InuY4sha]

Your question isn't about the C language, which is what we discuss

here. Assuming the kernel in question is Linux, you should ask in one
of the Linux newsgroups (possibly linux.dev.kernel, but check the
newsgroup first; all I know about it is that it exists).

I don't agree too much... my question is not about syntax in C, that's
true, but it's correlated with C. In any case, the NG linux.dev.kernel
seems to be dead since a long long time ago; What is left to me is a
couple of other groups with really few members. This one is probably
the best chance for me to get some information..
I'm in any case following your advice and try to post somewhere in a
"less off-topic newsgroup" if any exist..
I would like to clarify my position regarding this matter: NGs exist
with the precise scope to classify different arguments in order to
simplify the process of getting information about those. I agree with
you on the fact that mixing together off-topic stuff with correct
questions can cause a misusage of such an instrument. On the other
side I think that putting too much effort in indicating off-topic
questions *without trying to answer* them, is again not such a good
way to use the NG.
You could always find some reasons for a question to be off-topic, but
you MUST consider that having thousands of NGs for different topics
regardless of the fragmentation that this creates, can easily lead to
having lots of NGs with really few members, hence having poor chances
of getting an answer.
In this case I'm posting my question here with the sole idea in mind
to query a large number of people that could be familiar with what I'm
investigating. You can say that the method is not so much orthodox,
but it's effective.
Indeed I got an answer (and a good one), and I don't think that this
post can damage the NG more than any other spam message (I see
thounsands in this NG).

I hope you agree with me on some of those lines;

Cheers,
R

 

[InuY4sha]

Your question isn't about the C language, which is what we discuss

here. Assuming the kernel in question is Linux, you should ask in one
of the Linux newsgroups (possibly linux.dev.kernel, but check the
newsgroup first; all I know about it is that it exists).

I don't agree too much... my question is not about syntax in C, that's
true, but it's correlated with C. In any case, the NG linux.dev.kernel
seems to be dead since a long long time ago; What is left to me is a
couple of other groups with really few members. This one is probably
the best chance for me to get some information..
I'm in any case following your advice and try to post somewhere in a
"less off-topic newsgroup" if any exist..
I would like to clarify my position regarding this matter: NGs exist
with the precise scope to classify different arguments in order to
simplify the process of getting information about those. I agree with
you on the fact that mixing together off-topic stuff with correct
questions can cause a misusage of such an instrument. On the other
side I think that putting too much effort in indicating off-topic
questions *without trying to answer* them, is again not such a good
way to use the NG.
You could always find some reasons for a question to be off-topic, but
you MUST consider that having thousands of NGs for different topics
regardless of the fragmentation that this creates, can easily lead to
having lots of NGs with really few members, hence having poor chances
of getting an answer.
In this case I'm posting my question here with the sole idea in mind
to query a large number of people that could be familiar with what I'm
investigating. You can say that the method is not so much orthodox,
but it's effective.
Indeed I got an answer (and a good one), and I don't think that this
post can damage the NG more than any other spam message (I see
thounsands in this NG).

I hope you agree with me on some of those lines;

Cheers,
R

 

[Nick Keighley]

I don't agree too much...

but you're wrong

the topic of this ng is the C programming language and
*not* the systems that happen to be written in C.

my question is not about syntax in C, that's
true, but it's correlated with C. In any case, the NG linux.dev.kernel
seems to be dead since a long long time ago;

look for another linux group then. I understand comp.unix.programming
(?)
has a lot of Linux expertise.

[...] I think that putting too much effort in indicating off-topic
questions *without trying to answer* them, is again not such a good
way to use the NG.

the problem is you have no way of judging the quality of
an off-topic answer. For instance "Antonius Twink" may indeed
be a guru at Linux kernal i/o. Or he may not. If he was
poting on a ng with great kernal expertise then errors or
ommissions would be quickly picked up.

I hope you agree with me on some of those lines;

mostly not, no

 

[Ian Collins]

I would like to clarify my position regarding this matter: NGs exist
with the precise scope to classify different arguments in order to
simplify the process of getting information about those. I agree with
you on the fact that mixing together off-topic stuff with correct
questions can cause a misusage of such an instrument. On the other
side I think that putting too much effort in indicating off-topic
questions *without trying to answer* them, is again not such a good
way to use the NG.

A language news group such as this attracts programmers form a wide
range of platforms. Maybe one or more may have knowledge of a
particular domain detail, but many more will be found in a group
dedicated to that domain If you were to post a POSIX specific question,
I might be able answer it here, but I would still refer you to
comp.unix.programmer where you would benefit from the specialists who
read that group. There details of your question would be of general
interest, here they would be noise to many readers.

Some say ignore off topic posts, even if you know where the question
should be asked, but I say that helps no one. Redirecting posters to
the most appropriate group it the best way to help them.

If you don't know where to redirect the poster, then the best course of
action is to ignore the post.

 

[Keith Thompson]

Indeed I got an answer (and a good one), and I don't think that this
post can damage the NG more than any other spam message (I see
thounsands in this NG).

If your standard is "no more damaging than spam", you should re-think
your criteria.

 

[Kenny McCormack]

If your standard is "no more damaging than spam", you should re-think
your criteria.

The OP's point is that it would be a Good Thing if the "regs" could just
silently ignore stuff they don't like (because it offends their sense of
"on-topic-ness") the same way they (quite successfully) silently ignore
the (other) spam.

That they don't/can't, shows their hypocrisy.

 

[Kenny McCormack]

To the OP: I don't believe-in/support the stuff I am about to write
(after this introductory paragraph). Rather, I am giving you the
position held by the loony regulars of this ng, who strongly resemble
not the scientists that you would expect to find on a Usenet group,
particularly one of a technical bent, but rather, religious fanatics.
That (so I am told) many of the reg posters here are, in fact, religious
nutters in real life, should come as no surprise.

I don't agree too much... my question is not about syntax in C, that's
true, but it's correlated with C. In any case, the NG linux.dev.kernel
seems to be dead since a long long time ago; What is left to me is a
couple of other groups with really few members. This one is probably
the best chance for me to get some information..

As they have pointed out, what you believe or agree doesn't matter a
whit. They have religious certitude on their side. They are in a
position to tell you what *is*.

Note that certitude is the province of religion, not science.

 

[Antoninus Twink]

Your question isn't about the C language, which is what we discuss
here. Assuming the kernel in question is Linux, you should ask in one
of the Linux newsgroups (possibly linux.dev.kernel, but check the
newsgroup first; all I know about it is that it exists).

I don't agree too much... my question is not about syntax in C, that's
true, but it's correlated with C. In any case, the NG linux.dev.kernel
seems to be dead since a long long time ago; What is left to me is a
couple of other groups with really few members. This one is probably
the best chance for me to get some information.. [snip]
In this case I'm posting my question here with the sole idea in mind
to query a large number of people that could be familiar with what I'm
investigating. You can say that the method is not so much orthodox,
but it's effective.
Indeed I got an answer (and a good one), and I don't think that this
post can damage the NG more than any other spam message (I see
thounsands in this NG).

Thanks - I'm glad it was helpful.

As you've discovered, some of the regular posters here believe strongly
that the limits of topicality in this group should be defined extremely
strictly. Most groups have a FAQ to avoid repeating the same thing over
and over again; clc is the opposite - many people believe that the
questions already answered in the FAQ are pretty well the only thing
that's topical!

As I said, this is the belief of some posters here. The fact that they
express this view aggressively and authoritatively, and claim to speak
for the whole group, doesn't change the fact that it's just the belief
of a certain fraction of the posters.

Others would like to see this newsgroup be a vibrant forum where
real-life C developers can discuss all aspects of C programming in the
real world. Attempting to achieve this utopia by patiently convincing
the people described above by reasoned argument is doomed to failure.
It's best to ignore them, and just get on with asking interesting C
questions, and providing useful answers.

Please don't be discouraged from posting further questions here! There
are many experts here, on everything from Windows C programming to
embedded C programming, all the way through POSIX network development,
Linux kernel development, and everything else you can imagine. Whatever
question you come up with, there's someone here who'll know the answer.
Some people will refuse to tell you the answer, for the reasons
discussed above. But the best way to encourage more people to answer
questions in their fields of expertise is by building a positive
atmosphere where people ask C-related questions freely and frankly, and
where as many of those questions as possible get useful answers.

 

[Kenny McCormack]

Thanks - I'm glad it was helpful.

As you've discovered, some of the regular posters here believe strongly
that the limits of topicality in this group should be defined extremely
strictly. Most groups have a FAQ to avoid repeating the same thing over
and over again; clc is the opposite - many people believe that the
questions already answered in the FAQ are pretty well the only thing
that's topical!

As I said, this is the belief of some posters here. The fact that they
express this view aggressively and authoritatively, and claim to speak
for the whole group, doesn't change the fact that it's just the belief
of a certain fraction of the posters.

Others would like to see this newsgroup be a vibrant forum where
real-life C developers can discuss all aspects of C programming in the
real world. Attempting to achieve this utopia by patiently convincing
the people described above by reasoned argument is doomed to failure.
It's best to ignore them, and just get on with asking interesting C
questions, and providing useful answers.

Please don't be discouraged from posting further questions here! There
are many experts here, on everything from Windows C programming to
embedded C programming, all the way through POSIX network development,
Linux kernel development, and everything else you can imagine. Whatever
question you come up with, there's someone here who'll know the answer.
Some people will refuse to tell you the answer, for the reasons
discussed above. But the best way to encourage more people to answer
questions in their fields of expertise is by building a positive
atmosphere where people ask C-related questions freely and frankly, and
where as many of those questions as possible get useful answers.

Hear, Hear!!!

 

[Keith Thompson]

Please don't be discouraged from posting further questions here! There
are many experts here, on everything from Windows C programming to
embedded C programming, all the way through POSIX network development,
Linux kernel development, and everything else you can imagine. Whatever
question you come up with, there's someone here who'll know the answer.
Some people will refuse to tell you the answer, for the reasons
discussed above. But the best way to encourage more people to answer
questions in their fields of expertise is by building a positive
atmosphere where people ask C-related questions freely and frankly, and
where as many of those questions as possible get useful answers.

(The following is addressed to InuY4sha, the original poster.)

Yes, feel free to post questions *about the C programming language*
here. There's plenty to discuss (no, it's not just about casting
malloc and the return type of main).

Your question, however, was about the Linux kernel, not about the C
language. As such, it would have been perfectly appropriate in one of
the Linux newsgroups. I'm not sure which one would be best, but the
last time I looked my news server carried 700 newsgroup with "linux"
in their names. You happened to get an answer, which might even be
correct, but it's hard to tell since few of the people who read *this
newsgroup* are able to verify the information.

Not too long ago, a survey was carried out here in comp.lang.c on what
the topicality guidelines should be. The vast majority of those who
bothered to respond were in favor of keeping the guidelines fairly
strict. Antoninus Twink and the other trolls were perfectly free to
participate in the discussion, but they apparently prefer to whine
about others while making no real contribution themselves. (AT has
recently changed his tactics, but is no less a troll.)

The guidelines are not arbitrary. Some years ago, comp.lang.c++
started tolerating any posts that were even tangentially related to
C++, including system-specific discussions that would have yielded
better information in system-specific newsgroups. The result: the
groups signal-to-noise ratio dropped, many of the regulars who were
actually interested in discussing the language left, and the group
almost died. It recovered, but only after several years.

Suggested reading:

http://www.ungerhu.com/jxh/clc.welcome.txt
http://www.stanford.edu/~blp/writings/clc/off-topic.html

And you might want to take a look at Antoninus Twink's posting
history.

 

[Richard]

(The following is addressed to InuY4sha, the original poster.)

Yes, feel free to post questions *about the C programming language*
here. There's plenty to discuss (no, it's not just about casting
malloc and the return type of main).

Your question, however, was about the Linux kernel, not about the C
language. As such, it would have been perfectly appropriate in one of
the Linux newsgroups. I'm not sure which one would be best, but the
last time I looked my news server carried 700 newsgroup with "linux"
in their names. You happened to get an answer, which might even be
correct, but it's hard to tell since few of the people who read *this
newsgroup* are able to verify the information.

Not too long ago, a survey was carried out here in comp.lang.c on what
the topicality guidelines should be. The vast majority of those who
bothered to respond were in favor of keeping the guidelines fairly
strict. Antoninus Twink and the other trolls were perfectly free to

Primarily because the more useful posters have killfiled the majority
of the clique and do not respond to their nonsense.

participate in the discussion, but they apparently prefer to whine
about others while making no real contribution themselves. (AT has
recently changed his tactics, but is no less a troll.)

It would appear that you are the troll here. If you don't agree with ATs
posts then do not respond to them. This might surprise you - but you are
not in charge. And neither is Chuck. Nor RH. Adult programmers can talk
about C related issues if they see fit. If you do not like it, go away
and start your own "pay to play" site. Many of the threads which start
here are interesting in relation to C and it is not up to you to censor
such. People do not necessarily want to find new groups for each subject
because pretentious know alls have decided to try and limit the scope of
the group. I have learnt a lot from some of the C related "break out"
topics here which I would not have done had the threads not developed
here. You make more noise complaining than any real Off Topic
posts. Once more - don't like it? Ignore it or killfile it. It will go
away.

I can think of no better group to discuss, say, debugging techniques for
using a debugger to help fix broken C than here. Why? Because C
programmers come here. Why? Look at the group's name. Optimisation
ditto. General multiplatform tools - ditto.

 

[Keith Thompson]

It would appear that you are the troll here. If you don't agree with ATs
posts then do not respond to them. This might surprise you - but you are
not in charge.

[...]

You obviously don't agree with my posts, and yet you seem to be unable
to resist the temptation to respond to them. Think about your own
signal-to-noise ratio before you criticize others.

 

[Kenny McCormack]

InuY4sha, just ignore Keith Thompson. He is a lunatic. I think that
should be clear by now.

 

[Kenny McCormack]

(The following is addressed to InuY4sha, the original poster.)

Yes, feel free to post questions *about the C programming language*
here. There's plenty to discuss (no, it's not just about casting
malloc and the return type of main).

No, but as AT pointed out, CLC is unique in that the only things that
are "on-topic" are precisely what is in the FAQ. So, in any other
group the point of the FAQ is to list the things that are decided so
that we don't have to talk about them - i.e., we are free to discuss
other things. This is quite liberating. In CLC, the things in the FAQ
(and I include "the standard" as essentially part of the FAQ - i.e., it
is part of the exisitng body of text) are the only things that can be
discussed. Strange, but true...

 

[Kenny McCormack]

It would appear that you are the troll here. If you don't agree with ATs
posts then do not respond to them. This might surprise you - but you are
not in charge.

[...]

You obviously don't agree with my posts, and yet you seem to be unable
to resist the temptation to respond to them. Think about your own
signal-to-noise ratio before you criticize others.

Pot.

Kettle.

Black.