TCP/UDP

TCP/UDP

[Nick Krause]

Hey Guys,
After Searching the kernel Docs there is very little information on
this for new developers. I want to know more about how
the kernel code is written to handle TCP/UDP as even with Google and
kernel programming books it's not good enough to
learn how to write code for this particular subsystem at a high level.
Cheers Nick

TCP/UDP

[Afonso Bordado]

I don't mean to be rude, but about two days ago you said that you
would not mail this mailing list until you completed the eudyptula
challenge, please stick to this policy.

As per your question, start by reading and completely understanding
the TCP/IP Protocol and Linux sockets, write some user space test
applications such as a IM client, and keep writing these applications
until you are confident that you can understand the kernel code,then
you should do what you said three days ago and read the kernel code
and not mail the mailing list for a few months, i say this because
people are getting saturated at you and your disregard for the
community and the people involved in it.

Maybe you were just searching the wrong phrases/keywords, but there is
an enormous amount of information regarding TCP/IP and the Linux
kernel

http://unix.stackexchange.com/questions/45160/books-resources-which-explain-tcp-ip-kernel-implementation


This stack exchange question seems to be related.

2014-08-18 17:25 GMT+01:00 Nick Krause <xerofoify@gmail.com>:
> Hey Guys,
> After Searching the kernel Docs there is very little information on
> this for new developers. I want to know more about how
> the kernel code is written to handle TCP/UDP as even with Google and
> kernel programming books it's not good enough to
> learn how to write code for this particular subsystem at a high level.
> Cheers Nick
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

TCP/UDP

[Nick Krause]

On Mon, Aug 18, 2014 at 12:51 PM, Afonso Bordado
<afonsobordado@gmail.com> wrote:
> I don't mean to be rude, but about two days ago you said that you
> would not mail this mailing list until you completed the eudyptula
> challenge, please stick to this policy.
>
> As per your question, start by reading and completely understanding
> the TCP/IP Protocol and Linux sockets, write some user space test
> applications such as a IM client, and keep writing these applications
> until you are confident that you can understand the kernel code,then
> you should do what you said three days ago and read the kernel code
> and not mail the mailing list for a few months, i say this because
> people are getting saturated at you and your disregard for the
> community and the people involved in it.
>
> Maybe you were just searching the wrong phrases/keywords, but there is
> an enormous amount of information regarding TCP/IP and the Linux
> kernel
>
> http://unix.stackexchange.com/questions/45160/books-resources-which-explain-tcp-ip-kernel-implementation
>
>
> This stack exchange question seems to be related.
>
> 2014-08-18 17:25 GMT+01:00 Nick Krause <xerofoify@gmail.com>:
>> Hey Guys,
>> After Searching the kernel Docs there is very little information on
>> this for new developers. I want to know more about how
>> the kernel code is written to handle TCP/UDP as even with Google and
>> kernel programming books it's not good enough to
>> learn how to write code for this particular subsystem at a high level.
>> Cheers Nick
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
I was just curious. I will keep to my stated promise then.
Nick

TCP/UDP

[Valdis.Kletnieks at vt.edu]

On Mon, 18 Aug 2014 12:25:53 -0400, Nick Krause said:
> Hey Guys,
> After Searching the kernel Docs there is very little information on
> this for new developers. I want to know more about how
> the kernel code is written to handle TCP/UDP as even with Google and
> kernel programming books it's not good enough to
> learn how to write code for this particular subsystem at a high level.

Do we need to stick a "CAUTION: NO USER SERVICEABLE PARTS INSIDE" sticker
on there before you get the hint?

Let me quote a mail of yours from less than 24 hours ago:

> Further more I learn really fast  in my areas of interest, after my first year
> of programming I was already have build my own distro of Linux from Scratch,
> and after my second year was learning how to program embedded bootloaders and
> the like.  I am not lying this is no joke

If this is the truth, you should be having *zero* difficulty with
the Linux network stack.

Anyhow, I'm not feeling like digging up any good references for you,
because I have zero guarantee it's worth my time.  Beagleboads apparently
lasted all of 36 hours - why should I dig up references fo something that
you probably won't be interested in by the time I finish typing the mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140818/ee4c9070/attachment.bin 

TCP/UDP

[Nick Krause]

On Mon, Aug 18, 2014 at 12:57 PM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Mon, 18 Aug 2014 12:25:53 -0400, Nick Krause said:
>> Hey Guys,
>> After Searching the kernel Docs there is very little information on
>> this for new developers. I want to know more about how
>> the kernel code is written to handle TCP/UDP as even with Google and
>> kernel programming books it's not good enough to
>> learn how to write code for this particular subsystem at a high level.
>
> Do we need to stick a "CAUTION: NO USER SERVICEABLE PARTS INSIDE" sticker
> on there before you get the hint?
>
> Let me quote a mail of yours from less than 24 hours ago:
>
>> Further more I learn really fast  in my areas of interest, after my first year
>> of programming I was already have build my own distro of Linux from Scratch,
>> and after my second year was learning how to program embedded bootloaders and
>> the like.  I am not lying this is no joke
>
> If this is the truth, you should be having *zero* difficulty with
> the Linux network stack.
>
> Anyhow, I'm not feeling like digging up any good references for you,
> because I have zero guarantee it's worth my time.  Beagleboads apparently
> lasted all of 36 hours - why should I dig up references fo something that
> you probably won't be interested in by the time I finish typing the mail?
Valdis,
I was interested in both at the same time, just asked about Beagle-boards first.
I aren't having any difficulty with it , I just wanted to known more about this
area as the docs out there are terrible and not worth reading on this part of
the networking stack.

TCP/UDP

[Nick Krause]

On Mon, Aug 18, 2014 at 1:13 PM, Nick Krause <xerofoify@gmail.com> wrote:
> On Mon, Aug 18, 2014 at 12:57 PM,  <Valdis.Kletnieks@vt.edu> wrote:
>> On Mon, 18 Aug 2014 12:25:53 -0400, Nick Krause said:
>>> Hey Guys,
>>> After Searching the kernel Docs there is very little information on
>>> this for new developers. I want to know more about how
>>> the kernel code is written to handle TCP/UDP as even with Google and
>>> kernel programming books it's not good enough to
>>> learn how to write code for this particular subsystem at a high level.
>>
>> Do we need to stick a "CAUTION: NO USER SERVICEABLE PARTS INSIDE" sticker
>> on there before you get the hint?
>>
>> Let me quote a mail of yours from less than 24 hours ago:
>>
>>> Further more I learn really fast  in my areas of interest, after my first year
>>> of programming I was already have build my own distro of Linux from Scratch,
>>> and after my second year was learning how to program embedded bootloaders and
>>> the like.  I am not lying this is no joke
>>
>> If this is the truth, you should be having *zero* difficulty with
>> the Linux network stack.
>>
>> Anyhow, I'm not feeling like digging up any good references for you,
>> because I have zero guarantee it's worth my time.  Beagleboads apparently
>> lasted all of 36 hours - why should I dig up references fo something that
>> you probably won't be interested in by the time I finish typing the mail?
> Valdis,
> I was interested in both at the same time, just asked about Beagle-boards first.
> I aren't having any difficulty with it , I just wanted to known more about this
> area as the docs out there are terrible and not worth reading on this part of
> the networking stack.
Valdis,
In addition I generally learn 5 or 6 areas of a topic or program at
the same time so I
am just asking at different times. Just to make you and the other
developers have
an easier time I will paste my kernel interests below in a list.
Regards Nick
1. Networking
2. Usb, PCI , Networking and CPU Freq Drivers
3. Embedded Boards
4. Kernel Booting with UEFI(curiosity mostly)
5. Btrfs , F2FS ,NFS filesysems
6.  VFS
7. Process and Virtual Memory Subsystems
8. Memory Management

TCP/UDP

[Manish Katiyar]

On Mon, Aug 18, 2014 at 10:21 AM, Nick Krause <xerofoify@gmail.com> wrote:

> On Mon, Aug 18, 2014 at 1:13 PM, Nick Krause <xerofoify@gmail.com> wrote:
> > On Mon, Aug 18, 2014 at 12:57 PM,  <Valdis.Kletnieks@vt.edu> wrote:
> >> On Mon, 18 Aug 2014 12:25:53 -0400, Nick Krause said:
> >>> Hey Guys,
> >>> After Searching the kernel Docs there is very little information on
> >>> this for new developers. I want to know more about how
> >>> the kernel code is written to handle TCP/UDP as even with Google and
> >>> kernel programming books it's not good enough to
> >>> learn how to write code for this particular subsystem at a high level.
> >>
> >> Do we need to stick a "CAUTION: NO USER SERVICEABLE PARTS INSIDE"
> sticker
> >> on there before you get the hint?
> >>
> >> Let me quote a mail of yours from less than 24 hours ago:
> >>
> >>> Further more I learn really fast  in my areas of interest, after my
> first year
> >>> of programming I was already have build my own distro of Linux from
> Scratch,
> >>> and after my second year was learning how to program embedded
> bootloaders and
> >>> the like.  I am not lying this is no joke
> >>
> >> If this is the truth, you should be having *zero* difficulty with
> >> the Linux network stack.
> >>
> >> Anyhow, I'm not feeling like digging up any good references for you,
> >> because I have zero guarantee it's worth my time.  Beagleboads
> apparently
> >> lasted all of 36 hours - why should I dig up references fo something
> that
> >> you probably won't be interested in by the time I finish typing the
> mail?
> > Valdis,
> > I was interested in both at the same time, just asked about
> Beagle-boards first.
> > I aren't having any difficulty with it , I just wanted to known more
> about this
> > area as the docs out there are terrible and not worth reading on this
> part of
> > the networking stack.
> Valdis,
> In addition I generally learn 5 or 6 areas of a topic or program at
> the same time so I
> am just asking at different times. Just to make you and the other
> developers have
> an easier time I will paste my kernel interests below in a list.
> Regards Nick
> 1. Networking
> 2. Usb, PCI , Networking and CPU Freq Drivers
> 3. Embedded Boards
> 4. Kernel Booting with UEFI(curiosity mostly)
> 5. Btrfs , F2FS ,NFS filesysems
> 6.  VFS
> 7. Process and Virtual Memory Subsystems
> 8. Memory Management
>

This is amusing :-). So when you wrote linux from scratch, did you
implement it in the following order too ?

Thanks -
Manish



>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140818/497c46d7/attachment.html 

TCP/UDP

[Nick Krause]

On Mon, Aug 18, 2014 at 1:26 PM, Manish Katiyar <mkatiyar@gmail.com> wrote:
> On Mon, Aug 18, 2014 at 10:21 AM, Nick Krause <xerofoify@gmail.com> wrote:
>>
>> On Mon, Aug 18, 2014 at 1:13 PM, Nick Krause <xerofoify@gmail.com> wrote:
>> > On Mon, Aug 18, 2014 at 12:57 PM,  <Valdis.Kletnieks@vt.edu> wrote:
>> >> On Mon, 18 Aug 2014 12:25:53 -0400, Nick Krause said:
>> >>> Hey Guys,
>> >>> After Searching the kernel Docs there is very little information on
>> >>> this for new developers. I want to know more about how
>> >>> the kernel code is written to handle TCP/UDP as even with Google and
>> >>> kernel programming books it's not good enough to
>> >>> learn how to write code for this particular subsystem at a high level.
>> >>
>> >> Do we need to stick a "CAUTION: NO USER SERVICEABLE PARTS INSIDE"
>> >> sticker
>> >> on there before you get the hint?
>> >>
>> >> Let me quote a mail of yours from less than 24 hours ago:
>> >>
>> >>> Further more I learn really fast  in my areas of interest, after my
>> >>> first year
>> >>> of programming I was already have build my own distro of Linux from
>> >>> Scratch,
>> >>> and after my second year was learning how to program embedded
>> >>> bootloaders and
>> >>> the like.  I am not lying this is no joke
>> >>
>> >> If this is the truth, you should be having *zero* difficulty with
>> >> the Linux network stack.
>> >>
>> >> Anyhow, I'm not feeling like digging up any good references for you,
>> >> because I have zero guarantee it's worth my time.  Beagleboads
>> >> apparently
>> >> lasted all of 36 hours - why should I dig up references fo something
>> >> that
>> >> you probably won't be interested in by the time I finish typing the
>> >> mail?
>> > Valdis,
>> > I was interested in both at the same time, just asked about
>> > Beagle-boards first.
>> > I aren't having any difficulty with it , I just wanted to known more
>> > about this
>> > area as the docs out there are terrible and not worth reading on this
>> > part of
>> > the networking stack.
>> Valdis,
>> In addition I generally learn 5 or 6 areas of a topic or program at
>> the same time so I
>> am just asking at different times. Just to make you and the other
>> developers have
>> an easier time I will paste my kernel interests below in a list.
>> Regards Nick
>> 1. Networking
>> 2. Usb, PCI , Networking and CPU Freq Drivers
>> 3. Embedded Boards
>> 4. Kernel Booting with UEFI(curiosity mostly)
>> 5. Btrfs , F2FS ,NFS filesysems
>> 6.  VFS
>> 7. Process and Virtual Memory Subsystems
>> 8. Memory Management
>
>
> This is amusing :-). So when you wrote linux from scratch, did you implement
> it in the following order too ?
>
> Thanks -
> Manish
>
>
>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
Of course not, just listing it off.
Nick

TCP/UDP

[Denis Kirjanov]

No one will ever help you with the generic questions. _That is not how the
mailing list work_.
You really have to dig _on your own_ for that. Don't ask useless questions,
show us something concrete.

Better  invest your time in Stevens TCP/IP illustrated volumes....(1 and
2nd one)
and Unix network programming.

On Monday, August 18, 2014, Nick Krause <xerofoify@gmail.com> wrote:

> Hey Guys,
> After Searching the kernel Docs there is very little information on
> this for new developers. I want to know more about how
> the kernel code is written to handle TCP/UDP as even with Google and
> kernel programming books it's not good enough to
> learn how to write code for this particular subsystem at a high level.
> Cheers Nick
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org <javascript:;>
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>


-- 
Regards,
Denis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140818/a0af2b99/attachment.html 

TCP/UDP

[Nick Krause]

On Mon, Aug 18, 2014 at 1:31 PM, Denis Kirjanov <kirjanov@gmail.com> wrote:
> No one will ever help you with the generic questions. _That is not how the
> mailing list work_.
> You really have to dig _on your own_ for that. Don't ask useless questions,
> show us something concrete.
>
> Better  invest your time in Stevens TCP/IP illustrated volumes....(1 and 2nd
> one)
> and Unix network programming.
>
> On Monday, August 18, 2014, Nick Krause <xerofoify@gmail.com> wrote:
>>
>> Hey Guys,
>> After Searching the kernel Docs there is very little information on
>> this for new developers. I want to know more about how
>> the kernel code is written to handle TCP/UDP as even with Google and
>> kernel programming books it's not good enough to
>> learn how to write code for this particular subsystem at a high level.
>> Cheers Nick
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
> --
> Regards,
> Denis
That's fine, Denis I have no problems with that at all just stating my
areas of interest and if someone wants to
give me some kernel work for a newbie in that area I would be glad to
help :). Thanks for your support guys, I
didn't want to have to push the Linux from Scratch build but I have no
choice, sorry.
Nick

TCP/UDP

[Nick Krause]

On Mon, Aug 18, 2014 at 1:33 PM, Nick Krause <xerofoify@gmail.com> wrote:
> On Mon, Aug 18, 2014 at 1:31 PM, Denis Kirjanov <kirjanov@gmail.com> wrote:
>> No one will ever help you with the generic questions. _That is not how the
>> mailing list work_.
>> You really have to dig _on your own_ for that. Don't ask useless questions,
>> show us something concrete.
>>
>> Better  invest your time in Stevens TCP/IP illustrated volumes....(1 and 2nd
>> one)
>> and Unix network programming.
>>
>> On Monday, August 18, 2014, Nick Krause <xerofoify@gmail.com> wrote:
>>>
>>> Hey Guys,
>>> After Searching the kernel Docs there is very little information on
>>> this for new developers. I want to know more about how
>>> the kernel code is written to handle TCP/UDP as even with Google and
>>> kernel programming books it's not good enough to
>>> learn how to write code for this particular subsystem at a high level.
>>> Cheers Nick
>>>
>>> _______________________________________________
>>> Kernelnewbies mailing list
>>> Kernelnewbies at kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>>
>> --
>> Regards,
>> Denis
> That's fine, Denis I have no problems with that at all just stating my
> areas of interest and if someone wants to
> give me some kernel work for a newbie in that area I would be glad to
> help :). Thanks for your support guys, I
> didn't want to have to push the Linux from Scratch build but I have no
> choice, sorry.
> Nick
The reason I got into my mess here was not listening to testing
patches and over thinking the code.
Cheers Nick

fd type from number

[Loris Degioanni]

I'm looking for an efficient way to determine the type of an fd (file, 
socket...) given its number, from a kernel module.
The closest thing I found by looking at the kernel sources is 
sockfd_lookup(), which works but is limited to telling me if the fd is a 
socket or not.

Is there something else I can look at?

Thank you in advance,
Loris

one thing at a time

[Rik van Riel]

On 08/18/2014 01:13 PM, Nick Krause wrote:
> Valdis,
> I was interested in both at the same time, just asked about Beagle-boards first.
> I aren't having any difficulty with it , I just wanted to known more about this
> area as the docs out there are terrible and not worth reading on this part of
> the networking stack.
Nick,

the Linux kernel requires a lot of focus.

I have no doubt that you are smart enough to learn
things about the Linux kernel, but nobody is smart
enough to learn everything at once. Nobody.

If you are serious about learning Linux kernel internals,
it would be good to focus on one thing at a time.

One thing. Learn everything about it, before moving on
to the next topic.

Kernel hacking is much more about attitude than about
aptitude. Focus is the key.

one thing at a time

[Nick Krause]

On Mon, Aug 18, 2014 at 10:06 PM, Rik van Riel <riel@surriel.com> wrote:
> On 08/18/2014 01:13 PM, Nick Krause wrote:
>> Valdis,
>> I was interested in both at the same time, just asked about Beagle-boards first.
>> I aren't having any difficulty with it , I just wanted to known more about this
>> area as the docs out there are terrible and not worth reading on this part of
>> the networking stack.
> Nick,
>
> the Linux kernel requires a lot of focus.
>
> I have no doubt that you are smart enough to learn
> things about the Linux kernel, but nobody is smart
> enough to learn everything at once. Nobody.
>
> If you are serious about learning Linux kernel internals,
> it would be good to focus on one thing at a time.
>
> One thing. Learn everything about it, before moving on
> to the next topic.
>
> Kernel hacking is much more about attitude than about
> aptitude. Focus is the key.
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Absolutely, I am trying to learn btrfs and networking for now.
Cheers Nick

one thing at a time

[Nick Krause]

On Mon, Aug 18, 2014 at 10:55 PM, Nick Krause <xerofoify@gmail.com> wrote:
> On Mon, Aug 18, 2014 at 10:06 PM, Rik van Riel <riel@surriel.com> wrote:
>> On 08/18/2014 01:13 PM, Nick Krause wrote:
>>> Valdis,
>>> I was interested in both at the same time, just asked about Beagle-boards first.
>>> I aren't having any difficulty with it , I just wanted to known more about this
>>> area as the docs out there are terrible and not worth reading on this part of
>>> the networking stack.
>> Nick,
>>
>> the Linux kernel requires a lot of focus.
>>
>> I have no doubt that you are smart enough to learn
>> things about the Linux kernel, but nobody is smart
>> enough to learn everything at once. Nobody.
>>
>> If you are serious about learning Linux kernel internals,
>> it would be good to focus on one thing at a time.
>>
>> One thing. Learn everything about it, before moving on
>> to the next topic.
>>
>> Kernel hacking is much more about attitude than about
>> aptitude. Focus is the key.
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> Absolutely, I am trying to learn btrfs and networking for now.
> Cheers Nick
My issue now is that due to my issues I can't mail the right list for being
banned for my questions. If someone wants to talk to the other developers
about removing the ban that would be great and very helpful as I can my
questions to the right maintainers/developers.
Cheers Nick

one thing at a time

[Nick Krause]

On Mon, Aug 18, 2014 at 10:59 PM, Nick Krause <xerofoify@gmail.com> wrote:
> On Mon, Aug 18, 2014 at 10:55 PM, Nick Krause <xerofoify@gmail.com> wrote:
>> On Mon, Aug 18, 2014 at 10:06 PM, Rik van Riel <riel@surriel.com> wrote:
>>> On 08/18/2014 01:13 PM, Nick Krause wrote:
>>>> Valdis,
>>>> I was interested in both at the same time, just asked about Beagle-boards first.
>>>> I aren't having any difficulty with it , I just wanted to known more about this
>>>> area as the docs out there are terrible and not worth reading on this part of
>>>> the networking stack.
>>> Nick,
>>>
>>> the Linux kernel requires a lot of focus.
>>>
>>> I have no doubt that you are smart enough to learn
>>> things about the Linux kernel, but nobody is smart
>>> enough to learn everything at once. Nobody.
>>>
>>> If you are serious about learning Linux kernel internals,
>>> it would be good to focus on one thing at a time.
>>>
>>> One thing. Learn everything about it, before moving on
>>> to the next topic.
>>>
>>> Kernel hacking is much more about attitude than about
>>> aptitude. Focus is the key.
>>>
>>> _______________________________________________
>>> Kernelnewbies mailing list
>>> Kernelnewbies at kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>> Absolutely, I am trying to learn btrfs and networking for now.
>> Cheers Nick
> My issue now is that due to my issues I can't mail the right list for being
> banned for my questions. If someone wants to talk to the other developers
> about removing the ban that would be great and very helpful as I can my
> questions to the right maintainers/developers.
> Cheers Nick
I am working on btrfs for now. :) Thanks for the advice Rik.
Cheers Nick

one thing at a time

[Jason Ball]

I'm sure Avi is looking forward to your contribution...


On Tuesday, 19 August 2014, Nick Krause <xerofoify@gmail.com> wrote:

> On Mon, Aug 18, 2014 at 10:59 PM, Nick Krause <xerofoify@gmail.com
> <javascript:;>> wrote:
> > On Mon, Aug 18, 2014 at 10:55 PM, Nick Krause <xerofoify@gmail.com
> <javascript:;>> wrote:
> >> On Mon, Aug 18, 2014 at 10:06 PM, Rik van Riel <riel@surriel.com
> <javascript:;>> wrote:
> >>> On 08/18/2014 01:13 PM, Nick Krause wrote:
> >>>> Valdis,
> >>>> I was interested in both at the same time, just asked about
> Beagle-boards first.
> >>>> I aren't having any difficulty with it , I just wanted to known more
> about this
> >>>> area as the docs out there are terrible and not worth reading on this
> part of
> >>>> the networking stack.
> >>> Nick,
> >>>
> >>> the Linux kernel requires a lot of focus.
> >>>
> >>> I have no doubt that you are smart enough to learn
> >>> things about the Linux kernel, but nobody is smart
> >>> enough to learn everything at once. Nobody.
> >>>
> >>> If you are serious about learning Linux kernel internals,
> >>> it would be good to focus on one thing at a time.
> >>>
> >>> One thing. Learn everything about it, before moving on
> >>> to the next topic.
> >>>
> >>> Kernel hacking is much more about attitude than about
> >>> aptitude. Focus is the key.
> >>>
> >>> _______________________________________________
> >>> Kernelnewbies mailing list
> >>> Kernelnewbies at kernelnewbies.org <javascript:;>
> >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >> Absolutely, I am trying to learn btrfs and networking for now.
> >> Cheers Nick
> > My issue now is that due to my issues I can't mail the right list for
> being
> > banned for my questions. If someone wants to talk to the other developers
> > about removing the ban that would be great and very helpful as I can my
> > questions to the right maintainers/developers.
> > Cheers Nick
> I am working on btrfs for now. :) Thanks for the advice Rik.
> Cheers Nick
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org <javascript:;>
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>


-- 
--
Teach your kids Science, or somebody else will :/

jason at ball.net
vk2vjb at google.com <vk2flnx@google.com>
callsign: vk2vjb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140819/fc185d70/attachment.html 

fd type from number

[Greg Freemyer]

On August 18, 2014 8:46:16 PM EDT, Loris Degioanni <loris@draios.com> wrote:
>I'm looking for an efficient way to determine the type of an fd (file, 
>socket...) given its number, from a kernel module.
>The closest thing I found by looking at the kernel sources is 
>sockfd_lookup(), which works but is limited to telling me if the fd is
>a 
>socket or not.
>
>Is there something else I can look at?
>
>Thank you in advance.

Loris,

Apparently you replied to a different email then changed the subject.  Email clients that thread conversations based on "in-reply-to" will lump your supposedly new thread in with the one you replied to.  That guarantees a reduced audience of readers, especially considering the email you replied to.

You should repost by composing a brand new email.

Greg

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

one thing at a time

[Greg Freemyer]

On August 18, 2014 10:59:05 PM EDT, Nick Krause <xerofoify@gmail.com> wrote:
>On Mon, Aug 18, 2014 at 10:55 PM, Nick Krause <xerofoify@gmail.com>
>wrote:
>> On Mon, Aug 18, 2014 at 10:06 PM, Rik van Riel <riel@surriel.com>
>wrote:
>>> On 08/18/2014 01:13 PM, Nick Krause wrote:
>>>> Valdis,
>>>> I was interested in both at the same time, just asked about
>Beagle-boards first.
>>>> I aren't having any difficulty with it , I just wanted to known
>more about this
>>>> area as the docs out there are terrible and not worth reading on
>this part of
>>>> the networking stack.
>>> Nick,
>>>
>>> the Linux kernel requires a lot of focus.
>>>
>>> I have no doubt that you are smart enough to learn
>>> things about the Linux kernel, but nobody is smart
>>> enough to learn everything at once. Nobody.
>>>
>>> If you are serious about learning Linux kernel internals,
>>> it would be good to focus on one thing at a time.
>>>
>>> One thing. Learn everything about it, before moving on
>>> to the next topic.
>>>
>>> Kernel hacking is much more about attitude than about
>>> aptitude. Focus is the key.
>>>
>>> _______________________________________________
>>> Kernelnewbies mailing list
>>> Kernelnewbies at kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>> Absolutely, I am trying to learn btrfs and networking for now.
>> Cheers Nick
>My issue now is that due to my issues I can't mail the right list for
>being
>banned for my questions. If someone wants to talk to the other
>developers
>about removing the ban that would be great and very helpful as I can my
>questions to the right maintainers/developers.
>Cheers Nick

I checked my watch, then my sundial, and finally my calendar.  All said check back after beard has grown 6 additional inches.

I have no idea if you will ever be un-banned, but it certainly not going to happen in 2014.  I doubt seriously it will happen in 2015.

You do realize that most of the kernel devs do it both for a living and out of sheer love of the work.  Your participation the last few months impacted both in a negative way.  I've never heard of anyone being banned before, so you are novel.  None of us how long the blackball will stay in place, maybe forever.

Greg
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

fd type from number

[Loris Degioanni]

(resending making sure this is not part of another thread)

I'm looking for an efficient way to determine the type of an fd (file, 
socket...) given its number, from a kernel module.
The closest thing I found by looking at the kernel sources is 
sockfd_lookup(), which works but is limited to telling me if the fd is a 
socket or not.

Is there something else I can look at?

Thank you in advance,
Loris

fd type from number

[Daniel Baluta]

On Tue, Aug 19, 2014 at 6:38 PM, Loris Degioanni <loris@draios.com> wrote:
> (resending making sure this is not part of another thread)
>
> I'm looking for an efficient way to determine the type of an fd (file,
> socket...) given its number, from a kernel module.
> The closest thing I found by looking at the kernel sources is
> sockfd_lookup(), which works but is limited to telling me if the fd is a
> socket or not.
>
> Is there something else I can look at?

https://www.kernel.org/doc/Documentation/filesystems/files.txt

See point 4.

Daniel.

fd type from number

[Valdis.Kletnieks at vt.edu]

On Tue, 19 Aug 2014 08:38:24 -0700, Loris Degioanni said:

> I'm looking for an efficient way to determine the type of an fd (file,
> socket...) given its number, from a kernel module.

What problem are you trying to solve here?  There may be a better API for
your problem.  So step back - what are you trying to accomplish?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140819/a71bb92f/attachment.bin 

fd type from number

[Greg KH]

On Tue, Aug 19, 2014 at 08:38:24AM -0700, Loris Degioanni wrote:
> (resending making sure this is not part of another thread)
> 
> I'm looking for an efficient way to determine the type of an fd (file, 
> socket...) given its number, from a kernel module.

You don't have a "number" from within the kernel, you have a pointer to
the full file descriptor structure, right?  If so, what is missing from
that structure that you can not find?

> The closest thing I found by looking at the kernel sources is 
> sockfd_lookup(), which works but is limited to telling me if the fd is a 
> socket or not.
> 
> Is there something else I can look at?

What exactly are you trying to do with this?  And what does it matter
what "type" of thing a file descriptor is?  What can you do with that
information?

thanks,

greg k-h

fd type from number

[Loris Degioanni]

Sure, here's some more context.

I'm one of the developers of sysdig (www.sysdig.org), a tool that 
captures system calls and uses them to offer advanced system monitoring. 
One of the features that our diver offers is the tcpdump-derived concept 
of "snaplen": when a system call with a buffer is captured, it's 
possible to choose how many bytes of that buffer are copied to the 
driver capture buffer. This makes it possible to tune buffer utilization 
and CPU usage vs completeness of data.

Since this feature is important and heavily used, I'd like to extend it 
so that the user has per-fd-type snaplen control. A typical use case is: 
"I want 1000 bytes of each socket buffer, because I'm interested in 
looking at protocol activity, but I don't care about files and so I'm ok 
with just 20 bytes from them". In order for this feature to be useful, 
it needs to be very fast: we use tracepoints to capture system calls, so 
we slow down the original process if we take too long.

And since I'm here, let me expand my question. Another useful thing to 
do would be per-filename snaplen. Use case: "I want the whole content of 
reads and writes to files that are in /etc, but I want only 20 bytes 
from any other system call". This would I guess involve unpacking the 
file structure and retrieving the full file name. Is there any way to do 
it safely and efficiently?

Thanks,
Loris


On 8/19/2014 9:02 AM, Valdis.Kletnieks at vt.edu wrote:
> On Tue, 19 Aug 2014 08:38:24 -0700, Loris Degioanni said:
>
>> I'm looking for an efficient way to determine the type of an fd (file,
>> socket...) given its number, from a kernel module.
> What problem are you trying to solve here?  There may be a better API for
> your problem.  So step back - what are you trying to accomplish?

fd type from number

[Loris Degioanni]

On 8/19/2014 9:10 AM, Greg KH wrote:
> On Tue, Aug 19, 2014 at 08:38:24AM -0700, Loris Degioanni wrote:
>> (resending making sure this is not part of another thread)
>>
>> I'm looking for an efficient way to determine the type of an fd (file,
>> socket...) given its number, from a kernel module.
> You don't have a "number" from within the kernel, you have a pointer to
> the full file descriptor structure, right?  If so, what is missing from
> that structure that you can not find?

I do have the FD number, because it's coming from intercepting a system 
call.

>
>> The closest thing I found by looking at the kernel sources is
>> sockfd_lookup(), which works but is limited to telling me if the fd is a
>> socket or not.
>>
>> Is there something else I can look at?
> What exactly are you trying to do with this?  And what does it matter
> what "type" of thing a file descriptor is?  What can you do with that
> information?

I just sent another email with some explanation.

Loris

>
> thanks,
>
> greg k-h

one thing at a time

[Nick Krause]

On Tue, Aug 19, 2014 at 8:13 AM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
>
>
> On August 18, 2014 10:59:05 PM EDT, Nick Krause <xerofoify@gmail.com> wrote:
>>On Mon, Aug 18, 2014 at 10:55 PM, Nick Krause <xerofoify@gmail.com>
>>wrote:
>>> On Mon, Aug 18, 2014 at 10:06 PM, Rik van Riel <riel@surriel.com>
>>wrote:
>>>> On 08/18/2014 01:13 PM, Nick Krause wrote:
>>>>> Valdis,
>>>>> I was interested in both at the same time, just asked about
>>Beagle-boards first.
>>>>> I aren't having any difficulty with it , I just wanted to known
>>more about this
>>>>> area as the docs out there are terrible and not worth reading on
>>this part of
>>>>> the networking stack.
>>>> Nick,
>>>>
>>>> the Linux kernel requires a lot of focus.
>>>>
>>>> I have no doubt that you are smart enough to learn
>>>> things about the Linux kernel, but nobody is smart
>>>> enough to learn everything at once. Nobody.
>>>>
>>>> If you are serious about learning Linux kernel internals,
>>>> it would be good to focus on one thing at a time.
>>>>
>>>> One thing. Learn everything about it, before moving on
>>>> to the next topic.
>>>>
>>>> Kernel hacking is much more about attitude than about
>>>> aptitude. Focus is the key.
>>>>
>>>> _______________________________________________
>>>> Kernelnewbies mailing list
>>>> Kernelnewbies at kernelnewbies.org
>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>> Absolutely, I am trying to learn btrfs and networking for now.
>>> Cheers Nick
>>My issue now is that due to my issues I can't mail the right list for
>>being
>>banned for my questions. If someone wants to talk to the other
>>developers
>>about removing the ban that would be great and very helpful as I can my
>>questions to the right maintainers/developers.
>>Cheers Nick
>
> I checked my watch, then my sundial, and finally my calendar.  All said check back after beard has grown 6 additional inches.
>
> I have no idea if you will ever be un-banned, but it certainly not going to happen in 2014.  I doubt seriously it will happen in 2015.
>
> You do realize that most of the kernel devs do it both for a living and out of sheer love of the work.  Your participation the last few months impacted both in a negative way.  I've never heard of anyone being banned before, so you are novel.  None of us how long the blackball will stay in place, maybe forever.
>
> Greg
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
That's understandable and I hope to get back on, I did screw up and
yes I understand your points.
Cheers Nick

fd type from number

[Rohan Puri]

On Tue, Aug 19, 2014 at 10:04 PM, Loris Degioanni <loris@draios.com> wrote:
> Sure, here's some more context.
>
> I'm one of the developers of sysdig (www.sysdig.org), a tool that
> captures system calls and uses them to offer advanced system monitoring.
> One of the features that our diver offers is the tcpdump-derived concept
> of "snaplen": when a system call with a buffer is captured, it's
> possible to choose how many bytes of that buffer are copied to the
> driver capture buffer. This makes it possible to tune buffer utilization
> and CPU usage vs completeness of data.
>
> Since this feature is important and heavily used, I'd like to extend it
> so that the user has per-fd-type snaplen control. A typical use case is:
> "I want 1000 bytes of each socket buffer, because I'm interested in
> looking at protocol activity, but I don't care about files and so I'm ok
> with just 20 bytes from them". In order for this feature to be useful,
> it needs to be very fast: we use tracepoints to capture system calls, so
> we slow down the original process if we take too long.
>
> And since I'm here, let me expand my question. Another useful thing to
> do would be per-filename snaplen. Use case: "I want the whole content of
> reads and writes to files that are in /etc, but I want only 20 bytes
> from any other system call". This would I guess involve unpacking the
> file structure and retrieving the full file name. Is there any way to do
> it safely and efficiently?
>
> Thanks,
> Loris
>
>
> On 8/19/2014 9:02 AM, Valdis.Kletnieks at vt.edu wrote:
>> On Tue, 19 Aug 2014 08:38:24 -0700, Loris Degioanni said:
>>
>>> I'm looking for an efficient way to determine the type of an fd (file,
>>> socket...) given its number, from a kernel module.
>> What problem are you trying to solve here?  There may be a better API for
>> your problem.  So step back - what are you trying to accomplish?
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Hi Loris,

You can get the file type from the fd by doing something like this : -

struct file *file = fget(fd);
if(!file)
        return error;
assert(file->f_inode != NULL);
file_type = (file->f_inode->i_mode & S_IFMT) >> 12;

Also, you can make use of S_IS*(mode) macros, to check for file types.

NOTE: fget() makes use of current process's file_struct.

Regards,
- Rohan

fd type from number

[Loris Degioanni]

On 8/20/2014 2:33 AM, Rohan Puri wrote:
> On Tue, Aug 19, 2014 at 10:04 PM, Loris Degioanni <loris@draios.com> wrote:
>> Sure, here's some more context.
>>
>> I'm one of the developers of sysdig (www.sysdig.org), a tool that
>> captures system calls and uses them to offer advanced system monitoring.
>> One of the features that our diver offers is the tcpdump-derived concept
>> of "snaplen": when a system call with a buffer is captured, it's
>> possible to choose how many bytes of that buffer are copied to the
>> driver capture buffer. This makes it possible to tune buffer utilization
>> and CPU usage vs completeness of data.
>>
>> Since this feature is important and heavily used, I'd like to extend it
>> so that the user has per-fd-type snaplen control. A typical use case is:
>> "I want 1000 bytes of each socket buffer, because I'm interested in
>> looking at protocol activity, but I don't care about files and so I'm ok
>> with just 20 bytes from them". In order for this feature to be useful,
>> it needs to be very fast: we use tracepoints to capture system calls, so
>> we slow down the original process if we take too long.
>>
>> And since I'm here, let me expand my question. Another useful thing to
>> do would be per-filename snaplen. Use case: "I want the whole content of
>> reads and writes to files that are in /etc, but I want only 20 bytes
>> from any other system call". This would I guess involve unpacking the
>> file structure and retrieving the full file name. Is there any way to do
>> it safely and efficiently?
>>
>> Thanks,
>> Loris
>>
>>
>> On 8/19/2014 9:02 AM, Valdis.Kletnieks at vt.edu wrote:
>>> On Tue, 19 Aug 2014 08:38:24 -0700, Loris Degioanni said:
>>>
>>>> I'm looking for an efficient way to determine the type of an fd (file,
>>>> socket...) given its number, from a kernel module.
>>> What problem are you trying to solve here?  There may be a better API for
>>> your problem.  So step back - what are you trying to accomplish?
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> Hi Loris,
>
> You can get the file type from the fd by doing something like this : -
>
> struct file *file = fget(fd);
> if(!file)
>          return error;
> assert(file->f_inode != NULL);
> file_type = (file->f_inode->i_mode & S_IFMT) >> 12;
>
> Also, you can make use of S_IS*(mode) macros, to check for file types.
>
> NOTE: fget() makes use of current process's file_struct.
>
> Regards,
> - Rohan

Thanks Rohan,
and for kernels more recent than 3.14 I assume I need to use fdget 
instead of fget, right?

Loris

fd type from number

[Rohan Puri]

On Sat, Aug 23, 2014 at 12:33 AM, Loris Degioanni <loris@draios.com> wrote:
> On 8/20/2014 2:33 AM, Rohan Puri wrote:
>>
>> On Tue, Aug 19, 2014 at 10:04 PM, Loris Degioanni <loris@draios.com>
>> wrote:
>>>
>>> Sure, here's some more context.
>>>
>>> I'm one of the developers of sysdig (www.sysdig.org), a tool that
>>> captures system calls and uses them to offer advanced system monitoring.
>>> One of the features that our diver offers is the tcpdump-derived concept
>>> of "snaplen": when a system call with a buffer is captured, it's
>>> possible to choose how many bytes of that buffer are copied to the
>>> driver capture buffer. This makes it possible to tune buffer utilization
>>> and CPU usage vs completeness of data.
>>>
>>> Since this feature is important and heavily used, I'd like to extend it
>>> so that the user has per-fd-type snaplen control. A typical use case is:
>>> "I want 1000 bytes of each socket buffer, because I'm interested in
>>> looking at protocol activity, but I don't care about files and so I'm ok
>>> with just 20 bytes from them". In order for this feature to be useful,
>>> it needs to be very fast: we use tracepoints to capture system calls, so
>>> we slow down the original process if we take too long.
>>>
>>> And since I'm here, let me expand my question. Another useful thing to
>>> do would be per-filename snaplen. Use case: "I want the whole content of
>>> reads and writes to files that are in /etc, but I want only 20 bytes
>>> from any other system call". This would I guess involve unpacking the
>>> file structure and retrieving the full file name. Is there any way to do
>>> it safely and efficiently?
>>>
>>> Thanks,
>>> Loris
>>>
>>>
>>> On 8/19/2014 9:02 AM, Valdis.Kletnieks at vt.edu wrote:
>>>>
>>>> On Tue, 19 Aug 2014 08:38:24 -0700, Loris Degioanni said:
>>>>
>>>>> I'm looking for an efficient way to determine the type of an fd (file,
>>>>> socket...) given its number, from a kernel module.
>>>>
>>>> What problem are you trying to solve here?  There may be a better API
>>>> for
>>>> your problem.  So step back - what are you trying to accomplish?
>>>
>>>
>>> _______________________________________________
>>> Kernelnewbies mailing list
>>> Kernelnewbies at kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>> Hi Loris,
>>
>> You can get the file type from the fd by doing something like this : -
>>
>> struct file *file = fget(fd);
>> if(!file)
>>          return error;
>> assert(file->f_inode != NULL);
>> file_type = (file->f_inode->i_mode & S_IFMT) >> 12;
>>
>> Also, you can make use of S_IS*(mode) macros, to check for file types.
>>
>> NOTE: fget() makes use of current process's file_struct.
>>
>> Regards,
>> - Rohan
>
>
> Thanks Rohan,
> and for kernels more recent than 3.14 I assume I need to use fdget instead
> of fget, right?
fdget() calls __fget_light() internally & if you check out the definition
of __fget_light(), there is a comment there. Pasting it over here : -
/*
 * Lightweight file lookup - no refcnt increment if fd table isn't shared.
 *
 * You can use this instead of fget if you satisfy all of the following
 * conditions:
 * 1) You must call fput_light before exiting the syscall and returning
control
 *    to userspace (i.e. you cannot remember the returned struct file *
after
 *    returning to userspace).
 * 2) You must not call filp_close on the returned struct file * in between
 *    calls to fget_light and fput_light.
 * 3) You must not clone the current task in between the calls to fget_light
 *    and fput_light.
 *
 * The fput_needed flag returned by fget_light should be passed to the
 * corresponding fput_light.
 */

fdget() is different from fget() in 2 ways, if fd table is not shared,
meaning files_struct->count is 1 : -
1. Doesnt take rcu_read_lock()
2. Doesnt increment struct file->f_count.

else it behaves the same as fget(), *so yes i think you can use fdget().*
>
> Loris
>

Regards,
Rohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140823/52694a11/attachment-0001.html