Re: [OSSNA] Intro to kernel hacking tutorial

[Tobin C. Harding]

On Mon, Sep 02, 2019 at 10:08:54AM -0400, Valdis Klētnieks wrote:
> On Mon, 02 Sep 2019 15:42:19 +0300, Anatoly Pugachev said:
> 
> > is it intentionally that you use
> >
> > yes "" | make oldconfig
> >
> > instead of
> >
> > make olddefconfig
> 
> They do something different.  'olddefconfig' just takes the platform or
> architecture defconfig and updates it for any new CONFIG_* variables added
> since the last time the defconfig was updated in the tree.
> 
> yes "" | make oldconfig  does the same updating for new CONFIG_* variables, 
> but
> starts with the most recent .config - which produces wildly different results
> if the .config had previously been minimized by 'make localmodconfig' or other
> similar techniques.

Thanks Valdis, you're the man!


   Tobin




signature.asc
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [OSSNA] Intro to kernel hacking tutorial

[Tobin C. Harding]

On Sun, Sep 01, 2019 at 05:30:23AM +0530, Amit Kumar wrote:
> Hi,
> I think now your tutorial should be ready.

I do  not understand what this means sorry.  Is it a request for action?
The tutorial was a couple of weeks ago now, here is a link to the
material if that is what you were asking

https://github.com/tcharding/kernel/tree/master/workshop

Cheers,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [OSSNA] Intro to kernel hacking tutorial

[Tobin C. Harding]

On Fri, Jul 19, 2019 at 12:36:58PM +0300, Dan Carpenter wrote:
> On Fri, Jul 05, 2019 at 12:50:55PM +1000, Tobin C. Harding wrote:
> > Outcome will (hopefully) be a small patch set into drivers/staging/.
> > (Don't worry Greg only one group got to this stage last time, you
> > won't get flooded with patches :)
> 
> We're good at reviewing floods of patches.  Send away.
> 
> In the end what we want is people who will take over a driver and
> understand it completely and become the maintainer.  We've had a few
> people that did appointed themselves to become the maintainer of a
> random driver and move it out of staging.  But even if people don't make
> it all the way to become a maintainer, it's nice when they start down
> that path by focusing on one driver and trying to understand it as much
> as possible.
> 
> Most of the time when you look at a new staging driver, then you do want
> to clean up the white space just because it's hard to look at
> non-standard code.  So that's the first step.  But then maybe start at
> the probe and release functions and clean it up.  Keep your eyes open
> to any other mistakes or bugs you see.  Write them down.  Then the
> ioctls.  Etc.  Look at the TODO too.
> 
> The other thing I wish people knew was about the relationship with
> maintainers.  When you start out, you're virtually anonymous for the
> first couple patchsets.  We get so many and they blend together so we
> don't remember your name.  So don't think that we mean anything
> personally if we don't apply your patch.  We have forgotten about the
> patch as soon as we reply to it.  Don't panic and resend quickly.  You
> will be too stressed.  Wait until the next day.
> 
> In staging we really want to apply patches (unless it's in staging
> because we're going to remove the code).  I get annoyed with other
> staging reviewers who NAK patches because "I don't like churn" or
> whatever.
> 
> On the other hand, patches just "silencing checkpatch.pl" is not a valid
> justification for sending a patch.  Patches should make the code more
> readable.
> 
> Anyway, maintainers are not monsters.  Very few people have made me
> annoyed to the point where I refuse to review their code.  And everyone
> else is in my good books so that's fine.

Cool, points noted.  Thanks Dan


Tobin

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [OSSNA] Intro to kernel hacking tutorial

[Tobin C. Harding]

On Fri, Jul 05, 2019 at 10:40:43AM +0530, Amit Kumar wrote:
> On Fri, Jul 5, 2019 at 9:02 AM Amit Kumar  wrote:
> >
> > On Fri, Jul 5, 2019 at 8:21 AM Tobin C. Harding  wrote:
> > >
> > > Hi,
> > >
> > > I am doing a tutorial at OSSNA in San Diego on getting into kernel
> > > hacking.  I'm only a couple of years deep into kernel hacking so I
> > > wanted to reach out to those more experienced than myself (and those
> > > less experienced).
> > >
> > > Is there any thing that you would really like to see covered in this
> > > tutorial?
> > >
> > > If you are a grey beard is there anything that you have been lamenting
> > > us newbies not knowing/doing?
> > >
> > > If you are a newbie is there anything that you are struggling with that
> > > you really want to learn?
> > Thank you.
> > Where can I find your tutorial?

It's not written yet :)

> I forget to tell, merely creating and sending patches is not important.
> Also I would like to know how to manage patches, using git, mutt, quilt
> and so on.
> Sending patch through git-email is good. But different versions of patch.
> Applying patch from mutt. Replying to patch recipients.

Nice suggestions thanks, will work this in.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[OSSNA] Intro to kernel hacking tutorial

[Tobin C. Harding]

Hi,

I am doing a tutorial at OSSNA in San Diego on getting into kernel
hacking.  I'm only a couple of years deep into kernel hacking so I
wanted to reach out to those more experienced than myself (and those
less experienced).

Is there any thing that you would really like to see covered in this
tutorial?

If you are a grey beard is there anything that you have been lamenting
us newbies not knowing/doing?

If you are a newbie is there anything that you are struggling with that
you really want to learn?

Current format/content: the tutorial will attempt to bridge the gap in
the learning process between the 'first patch' page on kernelnewbies.org
wiki and being 'comfortable' patching the kernel via LKML.  Outcome will
(hopefully) be a small patch set into drivers/staging/.  (Don't worry
Greg only one group got to this stage last time, you won't get flooded
with patches :)

Thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Unable to understand a piece of code

[Tobin C. Harding]

On Mon, May 20, 2019 at 05:37:41AM +0530, Amit Kumar wrote:
> HI,
> 
> mm/slub.c: line 3973
> int __kmem_cache_shrink(struct kmem_cache *s)
> {
> int node;
> int i;
> struct kmem_cache_node *n;
> struct page *page;
> struct page *t;
> struct list_head discard;
> struct list_head promote[SHRINK_PROMOTE_MAX];
> unsigned long flags;
> int ret = 0;
> 
> flush_all(s);
> for_each_kmem_cache_node(s, node, n) {
> 
> How uninitialized variable node is being used in macro 
> for_each_kmem_cache_node?
>
> node is a local variable with no extern and not initialized.
> 
> mm/slab.h: line 490
> #define for_each_kmem_cache_node(__s, __node, __n) \
> for (__node = 0; __node < nr_node_ids; __node++) \

This _is_ the initialization of node.  Macros are kinda funky, there
isn't much more to say about that other than perhaps read up some more
about how macros work in C and read a bunch more macros in the kernel
e.g. include/linux/list.h

Good luck,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Where is PageHead defined in v5.0?

[Tobin C. Harding]

On Thu, Mar 28, 2019 at 01:50:47AM -0400, Valdis Klētnieks wrote:
> On Wed, 27 Mar 2019 17:23:05 -0700, Igor Pylypiv said:
> > and TESTPAGEFLAG defines PageHead:
> > #define TESTPAGEFLAG(uname, lname, policy) \
> > static __always_inline int Page##uname(struct page *page)
> > 
> > (https://elixir.bootlin.com/linux/v5.0.5/source/include/linux/page-flags.h#L215)
> 
> General tip:  If you're trying to find where the kernel defines FooBar,
> and 'git grep FooBar' only finds uses and no definitions, it probably
> means somebody got over-exuberant with the ## pre-processor
> operator
> 
> 'git grep Foo##' usually reveals the culprit. ;)

Awesome tip, thanks Valdis.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Where is PageHead defined in v5.0?

[Tobin C. Harding]

On Wed, Mar 27, 2019 at 05:23:05PM -0700, Igor Pylypiv wrote:
> On Wed, Mar 27, 2019 at 4:51 PM Tobin C. Harding  wrote:
> >
> > On Wed, Mar 27, 2019 at 07:34:58PM -0500, Jesse Simpson wrote:
> > > Hi Tobin,
> > >
> > > I took a look on my system, and I wasn't able to find where PageHead is
> > > defined either. I used grep to search for it as well as vim with ctags.
> > > Maybe it's hidden away in some built-in.a or binary file.
> >
> > Cheers Jesse, confirmation that I've not gone mad - that's a win.
> >
> > I'll repost this to mm-linux tomorrow if no one on here knows.
> >
> > thanks,
> > Tobin.
> >
> > ___
> > Kernelnewbies mailing list
> > Kernelnewbies@kernelnewbies.org
> > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 
> Hi Tobin and Jesse,
> 
> Neither grep nor ctags are going to help you here :)
> 
> PageHead is implicitly defined using macros __PAGEFLAG:
> __PAGEFLAG(Head, head, PF_ANY) CLEARPAGEFLAG(Head, head, PF_ANY)
> 
> (https://elixir.bootlin.com/linux/v5.0.5/source/include/linux/page-flags.h#L517)
> 
> __PAGEFLAG defines TESTPAGEFLAG:
> 
> (https://elixir.bootlin.com/linux/v5.0.5/source/include/linux/page-flags.h#L248)
> 
> and TESTPAGEFLAG defines PageHead:
> #define TESTPAGEFLAG(uname, lname, policy) \
> static __always_inline int Page##uname(struct page *page)
> 
> (https://elixir.bootlin.com/linux/v5.0.5/source/include/linux/page-flags.h#L215)

Thanks Igor.

> See, it is simple :)

hmmm macros - no further comment needed :)


thanks
Tobin

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Where is PageHead defined in v5.0?

[Tobin C. Harding]

On Wed, Mar 27, 2019 at 07:34:58PM -0500, Jesse Simpson wrote:
> Hi Tobin,
> 
> I took a look on my system, and I wasn't able to find where PageHead is
> defined either. I used grep to search for it as well as vim with ctags.
> Maybe it's hidden away in some built-in.a or binary file.

Cheers Jesse, confirmation that I've not gone mad - that's a win.

I'll repost this to mm-linux tomorrow if no one on here knows.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Where is PageHead defined in v5.0?

[Tobin C. Harding]

Hi,

I cannot locate the definition of PageHead?  It seems to have
disappeared after v4.0?  I can see it defined as a function here:


https://elixir.bootlin.com/linux/v4.0/source/include/linux/page-flags.h#L401

But on the mainline (v5.1-rc2) I get:

$ git grep ' PageHead'
include/linux/page-flags.h:int PageHeadHuge(struct page *page);
include/linux/page-flags.h: return PageHead(page);
include/linux/page-flags.h: return PageHead(page) && 
test_bit(PG_double_map, [1].flags);
mm/hugetlb.c:   return PageHead(page) && PagePrivate([1]);
mm/hugetlb.c: * PageHeadHuge() only returns true for hugetlbfs head page, but 
not for
mm/hugetlb.c:int PageHeadHuge(struct page *page_head)

Clearly it is defined _somewhere_.   Anyone any idea what brain
dysfunction I am having right now?

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: make modules_install install is failing

[Tobin C. Harding]

On Tue, Feb 05, 2019 at 11:30:53AM +0530, Bharath Vedartham wrote:
> Hi all,
> 
> I am unable to execute make modules_install install. 
> I get the following error:

Could you show the complete commands you are trying please

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Boot all yes config kernel with QEMU

[Tobin C. Harding]

On Tue, Oct 23, 2018 at 12:22:44AM -0400, valdis.kletni...@vt.edu wrote:
> On Tue, 23 Oct 2018 13:56:42 +1100, "Tobin C. Harding" said:
> 
> > I'd like to build and boot an allyesconfig kernel with QEMU.  Building
> > is no problem but when I try to boot it I get problems because the host
> > system does not support features requested by the VM.
> >
> > How does one go about testing an allyesconfig kernel?
> 
> As you have noticed, there's no guarantee that a allyesconfig kernel will 
> boot in
> a VM because the VM doesn't support something.  Note that you're going to have
> the exact same issues booting on real hardware - you'll discover that there's 
> configs
> that won't boot on real hardware either - and even if it boots, you'll 
> probably not have
> the I/O devices to test even a third of the drivers unless you have a really 
> well stocked
> test lab.
> 
> But then, all(yes|mod|no)config aren't intended for actual booting and 
> testing - they're
> pretty much build testing all the options in one build.
> 
> Basically, one of two things happen after building an all-something-config:
> 
> 1) The build completes and you get on with your life
> 
> 2) The build fails, and you get to send an email telling the maintainer that
> their driver for the Frobnozz 1300 Widget won't build in =y in kernel 
> 4.21-rc2,
> or whatever your build died on.

I love this answer :)  thanks Valdis.  If you are taking a walk and feel
like pondering something; any ideas how I could get the most files
possible to show up in /proc and /sys?

thanks,
Tobin.

signature.asc
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Boot all yes config kernel with QEMU

[Tobin C. Harding]

Hi,

I'd like to build and boot an allyesconfig kernel with QEMU.  Building
is no problem but when I try to boot it I get problems because the host
system does not support features requested by the VM.

How does one go about testing an allyesconfig kernel?

Back story: I'm trying to set up some CI infrastructure to run
scripts/leaking_addresses.pl against the various stable kernels.

thanks,
Tobin.

signature.asc
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: dev process - reduce mistakes

[Tobin C. Harding]

On Tue, Sep 18, 2018 at 10:01:19PM -0400, Cindy-Sue Causey wrote:
> On 9/18/18, Tobin C. Harding  wrote:
> > Hi,
> >
> > I'm after some advice from those more experienced with [kernel]
> > development please.
> >
> > What systems do you have in place to help catch mistakes?  In other
> > words; what processes do you use when coding and submitting patches to
> > help eliminate simple mistakes?  So far my best method is getting a
> > patch [set] ready then waiting until the next day before reviewing the
> > set and submitting.  I am facing an issue where by when doing (less than
> > super interesting) large patch sets (like docs fixes) that by the time I
> > get to the final review my eyes glaze over and I'm still missing
> > mistakes.
> >
> > My future maintainers will thank you ;)
> 
> 
> For the docs part of what you're doing, *I* read what I write out loud
> and deliberately very slowly so that I actually see each word. I
> *empathize* with you. I experience something similar regarding my
> often long winded emails. I'll proofread literally 10 or 15 times then
> see that one last mistake...
> 
> That I MISSED... as the email is disappearing out of sight because it
> has just been sent to a listserv. :D
> 
> Reading out loud **slower** than I normally would helps me see AND
> hear mistakes. If I read at a normal speed, even if I do so out loud,
> it's some kind of a Human nature thing that I'll keep reading my
> mistakes wrongly by mentally "glossing over" those mistakes instead of
> seeing them for the oopsies they are. Instead of catching those
> mistakes and fixing them, I just keep saying them WRONG out loud over
> and over (AND over) if I do so at a normal conversational speaking
> speed. :))
> 
> Have fun!
> 
> Cindy :)

Awesome, thanks Cindy.  Just the sort of tip I was after.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: dev process - reduce mistakes

[Tobin C. Harding]

On Tue, Sep 18, 2018 at 08:01:22PM -0400, valdis.kletni...@vt.edu wrote:
> On Wed, 19 Sep 2018 09:35:36 +1000, "Tobin C. Harding" said:
> > Hi,
> >
> > I'm after some advice from those more experienced with [kernel]
> > development please.
> >
> > What systems do you have in place to help catch mistakes?  In other
> > words; what processes do you use when coding and submitting patches to
> > help eliminate simple mistakes?
> 
> Same way you verify it for any other large programming project.
> 
> 'make clean && make && make install && shutdown -r now'
> 
> 1) Verify no compile errors.
> 
> 2) Verify no unexplained compile warnings. gcc *does* screw up and whine about
> things incorrectly on occasion because it doesn't know everything - "variable
> may be used uninitialized" is a famous one, usually emitted because there's
> program logic it can't see. For instance, code like:
> 
> int oddball;
> for (i=0;i  if (wombat > 5) oddball = 7;
>  if (frobozz) quux = oddball;
> }
> 
> and there's a reason known to programmer but not compiler
> that guarantees that wombat > 5 will always happen at least once
> before frobozz becomes true.
> 
> But in general, unless you can *prove* the compiler is false-positive on
> a warning, fix the warning. ;)
> 
> 2a) (optional) Install 'sparse' and do a 'make C=2' and see if that complains 
> about
> anything that gcc didn't...
> 
> 3) Test that it actually boots and does whatever your patch is supposed to do.
> 
> See? And here you thought it was difficult :)



Thanks for your response Valdis (especially the wombat reference).  I'm
talking though about more brain dead mistakes like:

- Muddling up changes between patches when rebasing
- Missing an instance of a series of the same changes (usually because
  you did 100 of them and one slipped past when viewing the diff)


Things that don't make the compiler or static analysis complain.  I made
an improvement on my method today and that was to review patch sets
[almost] ready for submission first thing in the day so your eyes/brain
is fresh.

These sort of 'soft' ideas I'm after please.  I'm sure the old fellas
have a bunch of them that they do unconsciously but any that any one can
think of would be great to hear.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

dev process - reduce mistakes

[Tobin C. Harding]

Hi,

I'm after some advice from those more experienced with [kernel]
development please.

What systems do you have in place to help catch mistakes?  In other
words; what processes do you use when coding and submitting patches to
help eliminate simple mistakes?  So far my best method is getting a
patch [set] ready then waiting until the next day before reviewing the
set and submitting.  I am facing an issue where by when doing (less than
super interesting) large patch sets (like docs fixes) that by the time I
get to the final review my eyes glaze over and I'm still missing
mistakes.

My future maintainers will thank you ;)


thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Linux FS design and implementation book

[Tobin C. Harding]

On Sat, Sep 15, 2018 at 07:33:51AM +0530, inventsekar wrote:
> Hi All...
> Around last year I was searching for Linux Kernel FS design and
> implementation, and I found out a book by someone,.. a full length book,
> particularly, at the end of the book he/she included source code as well...

Might have been 'UNIX Filesystems' - by Steve D. Pate.  It has a 1300
LOC filesystem implementation in the back.


Tobin

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: regarding const variables/structures

[Tobin C. Harding]

On Wed, Sep 12, 2018 at 11:53:57PM +0530, inventsekar wrote:
> Thanks a ton, Valdis.

Another tip for you, read up on what 'top posting' is and don't do it :)

Shamelessly stealing Greg's 'top posting' link:

https://daringfireball.net/2007/07/on_top


Good luck,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Build using O=path

[Tobin C. Harding]

Thanks Luca, you had the winning entry!

On Mon, Sep 10, 2018 at 11:37:15AM +0200, Luca Ceresoli wrote:
> Hi,
> 
> On 10/09/2018 08:33, Tobin C. Harding wrote:
> > Hi,
> > 
> > I'm unable to build the kernel using the O=path/to/out option.  Am I
> > doing something brain dead?
> > 
> > $ cd $KERNEL
> > $ make mrproper
> > $ cp path/to/valid/config/file .config
> 
> Here you are copying a file in the source directory...
> 
> > $ make O=/abs/path/to/output
> > ...
> > scripts/kconfig/conf  --syncconfig Kconfig
> > ***
> > *** Configuration file ".config" not found!
> > ***
> > *** Please run some configurator (e.g. "make oldconfig" or
> > *** "make menuconfig" or "make xconfig").
> > ...
> > 
> > So I tried copying the .config file to the output directory
> > 
> > $ cp .config /abs/path/to/output
> > $ make O=/abs/path/to/output
> > ...
> >   Using /home/tobin/build/kernel/linux as source for kernel
> >   /home/tobin/build/kernel/linux is not clean, please run 'make mrproper'
> >   in the '/home/tobin/build/kernel/linux' directory.
> 
> ...and here's where the kernel complains about it.

Well explained, I did not garner this from the error messages.  Thanks.

> You have to put your .config file in the out-of-tree build dir, not the
> source dir. BTW this also allows you to have multiple builds woth
> different configs in different directories, all from the same set of
> sources -- how would it be possible if the config were in the source dir?
> 
> So, fix it as:
> 
> cd $KERNEL
> make mrproper
> make O=/abs/path/to/output # BTW: can be also relative

The key takeaway (for me) is that this invocation of make is expected to
fail (since we have not created the output directory or config file yet).

> cd /abs/path/to/output
> cp path/to/valid/config/file .config
> make olddefconfig # might be not needed, but harmless anyway
> make

I would not have realised that one can run make from the output
directory.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Build using O=path

[Tobin C. Harding]

Hi,

I'm unable to build the kernel using the O=path/to/out option.  Am I
doing something brain dead?

$ cd $KERNEL
$ make mrproper
$ cp path/to/valid/config/file .config
$ make O=/abs/path/to/output
...
scripts/kconfig/conf  --syncconfig Kconfig
***
*** Configuration file ".config" not found!
***
*** Please run some configurator (e.g. "make oldconfig" or
*** "make menuconfig" or "make xconfig").
...

So I tried copying the .config file to the output directory

$ cp .config /abs/path/to/output
$ make O=/abs/path/to/output
...
  Using /home/tobin/build/kernel/linux as source for kernel
  /home/tobin/build/kernel/linux is not clean, please run 'make mrproper'
  in the '/home/tobin/build/kernel/linux' directory.
/home/tobin/build/kernel/linux/Makefile:1091: recipe for target 'prepare3' 
failed
make[1]: *** [prepare3] Error 1
make[1]: Leaving directory '/home/tobin/build/kernel/output/master'
Makefile:146: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2


Same thing if I use KBUILD_OUTPUT instead of passing O=


thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [PATCH] vsprintf: fix build warning

[Tobin C. Harding]

CC'ing kernel newbies for anyone else trying to learn how linux-next
works.

On Fri, Jul 06, 2018 at 11:49:51AM -0400, Steven Rostedt wrote:
> On Fri, 6 Jul 2018 23:42:13 +0900
> Sergey Senozhatsky  wrote:
> 
> > On (07/06/18 15:47), Arnd Bergmann wrote:
> > [..]
> > > Fixes: bfe80ed3d7c7 ("vsprintf: add command line option 
> > > debug_boot_weak_hash")  
> > 
> > Seems like this one is still in linux-next.
> > Can we squash this patch and bfe80ed3d7c7?
> > 
> 
> I prefer not to do squashes unless absolutely necessary. Yes, it is in
> next, but even branches pulled into next should try to resist rebasing
> (I never rebase my next branch unless there is a real bug that will
> break bisecting).

Steve if you do not rebase your next branch and the branch ends up
containing fixes to patches like the above doesn't this mean that when
you do a pull request to Linus the branch you are asking to be pulled
will be too 'dirty' i.e. I thought that the pull request should be like
a patch set and only contain the 'final product' not every change that
was made during development?

I was under the impression that each maintainer constantly rebased their
next branches and that was why one has to checkout the tagged linux-next
each day instead of just pulling.  From information on the net somewhere
I have been checking out linux-next using this shell function

checkout-next () {
local branch='linux-next' 

git checkout master
git remote update linux-next
git branch -D $branch
git checkout -b $branch $(git tag -l "next-*" | tail -1)
}

Also, when my leaks tree got included in linux-next I was told that it
was ok to rebase and have since been rebasing mercilessly.


thanks in advance for your time,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Linux Networking Internals Question

[Tobin C. Harding]

On Sat, Jun 16, 2018 at 11:17:01PM +0530, V.Ravikumar wrote:
> Understood Rami Rosen. Thank you.
> 
> Regards
> Ravi
> 
> On Sat, Jun 16, 2018 at 11:10 PM, Rami Rosen  wrote:
> 
> > Hi Ravi,
> > The path that a packet goes through, from being received by the
> > network driver and up to kernel Layer 3 (IPV4/IPV6) and from
> > there to kernel Layer 4 (UDP/TCP/SCTP/other sockets) and from there to
> > userspace sockets is quite complex. The logic is heavy, on that path
> > there are lookups in routing tables, netfilter hooks, sanity checks,
> > interaction with other subsystems, and more.
> >
> > In order to try to simplify things, and not go into deep technical
> > details, we can say that generally the 5 tuple of the packet (SRC
> > address, DST address, SRC port, DST port and protocol) is what
> > determines to which socket it will go.
> >
> > Regards,
> > Rami Rosen
> > http://ramirose.wixsite.com/ramirosen
> >
> >
> >
> >
> > On 16 June 2018 at 20:16, V.Ravikumar 
> > wrote:
> > > Hi All,
> > >
> > > I wanted to know how a packet received will be handovered to a correct
> > user
> > > process.
> > > Basically I want to understand what are the various header parameters in
> > > packet which will help to  find the open socket descriptor  of respective
> > > user process. I'm not able to find the exact  answers in the web.

Or you could read Rami's book, you will learn a whole bunch :)


Tobin

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

tags

[Tobin C. Harding]

Hi,

A question relating to 'Acked-by:' and tags in general please.  Relates
to Documentation/process/submitting-patches.rst (sections 12 through 14).

For discussion, say a two patch series goes to version six and is then
applied to some maintainers tree.

On version three patch one of the series gets acked.  On version four
should patch one include the acked-by tag:

 - If patch one is unmodified?
 - If patch one is _trivially_ modified (update comment string etc)?

Finally, if version 6 (the version that is _correct_) gets an acked-by
on patch two does this final acked-by tag get included in the commit
log? The only two ways I can see this happening both seem wrong, hence
my question?

 - Developer submits another version with the tag.
 - Maintainer adds the tag when applying the series.


If the tag does not make its way into the commit log this implies that
the tag (and other tags?) are temporal and are mainly used by
maintainers at the time of merging patches?  Is this a fair comment?

However, from the documentation the 'Cc' tag is meant to keep a record
that a developer was included in the conversation and had opportunity to
comment but did not i.e. this tag is _not_ temporal but is a permanent
record.


Thanks in advance,
Tobin.


___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: where to send patch

[Tobin C. Harding]

On Tue, May 08, 2018 at 02:52:40AM +0530, Sumit Kumar wrote:
>     Hi,
> 
> When I use get_maintainer.pl script it give a list of names / addresses.
> 
> 1. Should I send to only one of them ?
> 
> 2. Should I put the first address in "To" field and the rest all in "CC" ?

Please see Documentation/process/submitting-patches.rst

Hope this helps
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [PATCH] scsi: eata: drop VLA in reorder()

[Tobin C. Harding]

Adding kernel newbies to CC because I pose a few noob questions :)
Adding Linus to CC because I quoted him.

On Sun, Mar 11, 2018 at 10:06:58PM +0100, Salvatore Mesoraca wrote:
> n_ready will always be less than or equal to MAX_MAILBOXES.
> So we avoid a VLA[1] and use fixed-length arrays instead.
> 
> [1] https://lkml.org/lkml/2018/3/7/621
> 
> Signed-off-by: Salvatore Mesoraca 
> ---
>  drivers/scsi/eata.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
> index 6501c33..202cd17 100644
> --- a/drivers/scsi/eata.c
> +++ b/drivers/scsi/eata.c
> @@ -2096,7 +2096,7 @@ static int reorder(struct hostdata *ha, unsigned long 
> cursec,
>   unsigned int k, n;
>   unsigned int rev = 0, s = 1, r = 1;
>   unsigned int input_only = 1, overlap = 0;
> - unsigned long sl[n_ready], pl[n_ready], ll[n_ready];
> + unsigned long sl[MAX_MAILBOXES], pl[MAX_MAILBOXES], ll[MAX_MAILBOXES];

I think we are going to see a recurring theme here.  MAX_MAILBOXES==64
so this patch adds 1536 bytes to the stack on a 64 bit machine or 768
bytes on a 32 bit machine.  Linus already commented on another VLA
removal patch that 768 was a lot of stack space.  That comment did,
however say 'deep in some transfer call chain'.  I don't know what a
'transfer call chain' (the transfer bit) is but is there some heuristic
we can use to know how deep is deep?  Or more to the point, is there some
heuristic we can use to know what is an acceptable amount of stack space
to use?

As far as this patch is concerned wouldn't a kmalloc (with GFP_ATOMIC)
be ok?  We are in an interrupt handler, can we assume that since IO has
just occurred that the IO will be so slow comparatively that a memory
allocation will be quick.  (assuming IO since eata.c only requests a
single irq line.)


thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Submitted patch, what to do next

[Tobin C. Harding]

On Wed, Mar 07, 2018 at 04:28:07PM +, Alex Arvelaez wrote:
> Hello,
> 
> I sent a small patch to the LKML. I sent it to one of the mantainers
> (as per get_mantainers.pl) and I CC-ed linux-ker...@vger.kernel.org.
> 
> I'm not entirely sure I did everything properly and I was wondering
> how long does it usually take to get any feedback? It's been a couple
> weeks since I sent it.

Resend after 14 days. Not a second before :)


Tobin

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Invalid module format

[Tobin C. Harding]

On Sun, Feb 25, 2018 at 12:04:30AM -0500, valdis.kletni...@vt.edu wrote:
> On Sun, 25 Feb 2018 13:34:41 +1100, "Tobin C. Harding" said:
> > On Fri, Feb 23, 2018 at 10:06:14PM -0500, valdis.kletni...@vt.edu wrote:
> > > OK, I'll bite - how can the kernel go into a reboot loop that doesn't get 
> > > to the
> > > grub menu?  (Hint: How does your system get from the BIOS splash screen to
> > > starting the kernel? :)
> >
> > That's not biting.  Having to pointed out when I say something
> > ridiculous is one of the reasons I like the kernel mailing lists so
> > much.
> >
> > Re-reading my original comment in your response makes it bleedingly
> > obvious that what I said was ridiculous.  I must have been selecting the
> > broken kernel in grub for it to boot - I still don't remember doing so
> > but it wouldn't be the first time my memory has bent reality.
> 
> Actually, there *is* a way you can end up in a reboot loop like that - if
> you set the grub menu timeout to zero.  That's actually pretty useful if
> you're building an embedded system that can't display the grub menu anyhow,
> or you want to save the few seconds of boot time (important if you're
> a wireless router or a smart TV or similar).

Being the type of guy who crashes his kernel constantly and breaks it
every other build this would be suicide.

> Of course, anybody who's done that to their system probably knows it,
> because if they installed a bum kernel, they've effectively bricked the box
> until they re-flash the image.

It's not bricked if you can re-flash it.


Tobin



___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Invalid module format

[Tobin C. Harding]

On Fri, Feb 23, 2018 at 10:06:14PM -0500, valdis.kletni...@vt.edu wrote:
> On Sat, 24 Feb 2018 10:29:33 +1100, "Tobin C. Harding" said:
> 
> > (For the record I happened to be trying to learn about linux-next myself
> > this morning and built a kernel that just goes into a reboot loop
> > without even getting to the grub menu.
> 
> OK, I'll bite - how can the kernel go into a reboot loop that doesn't get to 
> the
> grub menu?  (Hint: How does your system get from the BIOS splash screen to
> starting the kernel? :)

That's not biting.  Having to pointed out when I say something
ridiculous is one of the reasons I like the kernel mailing lists so
much.

Re-reading my original comment in your response makes it bleedingly
obvious that what I said was ridiculous.  I must have been selecting the
broken kernel in grub for it to boot - I still don't remember doing so
but it wouldn't be the first time my memory has bent reality.

> (Though I've seen kernels that flash the screen like they're rebooting but 
> they're
> actually hung in a loop, and I've heard some great bar stories about 
> kexec/kdump
> gone horribly astray and re-invoking the current kernel rather than the kexec 
> target
> kernel)

I appreciate your response Valdis, you always take the time to answer
nood questions.


thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Invalid module format

[Tobin C. Harding]

On Thu, Feb 22, 2018 at 02:42:23AM +0530, Srishti Sharma wrote:
> Hello,
> 
> While trying to load a module from the linux-next branch

Do you mean from linux-next tree or from a branch called linux-next in
some other tree?  (Not that it matters that much :)

>, I get the error
> that the module format is invalid, this was because the kernel I compiled
> was different from the kernel I was trying to load the module into, so I
> installed the kernel from the same source as the module, and it booted for
> only once right after the installation. When I try to boot into the same
> kernel, my system reboots. What should I do so that I am able to boot into
> it everytime ?

What are you trying to achieve?  Are you doing testing on linux-next or
do you just want to use the module?  If you just want to use the module
you could build the module for the current running kernel instead of
rebuilding the kernel.  Copy the module someplace and write a new
makefile same as you would if you were developing your own [test]
modules.

(For the record I happened to be trying to learn about linux-next myself
this morning and built a kernel that just goes into a reboot loop
without even getting to the grub menu.  It boots in a VM though so now
I'm playing with the cofig.)

Hope this helps,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: I'd like to contribute but I don't know how...

[Tobin C. Harding]

On Thu, Feb 22, 2018 at 09:25:39PM +, Alex Arvelaez wrote:
> On Thu, Feb 22, 2018 at 04:12:14AM +, Alex Arvelaez wrote:
> > On Wed, Feb 21, 2018 at 10:20:07PM -0500, valdis.kletni...@vt.edu wrote:
> > > On Thu, 22 Feb 2018 02:33:08 +, Alex Arvelaez said:
> > > > Hello,
> > > >
> > > > I'd like to contribute to the linux kernel eventually but I'm not sure
> > > 
> > > https://lists.kernelnewbies.org/pipermail/kernelnewbies/2017-April/017765.html
> > > 
> > > > how, I grabbed a copy of the source code and I found a FIXME that looks
> > > > like I could fix:
> > > >
> > > > /* File: /usr/src/linux/tools/perf/util/string.c
> > > >  * FIXME: replace this with an expression using log10() when we
> > > >  * find a suitable implementation, maybe the one in the dvb drivers...
> > > >  */
> > > 
> > > Step 0:  Verify that the comment still matches the code, *and* that the 
> > > change
> > > is still desired.  Hint:  Why do they want log10()? What does the current 
> > > code
> > > do? What, if anything, will break if you change it?
> > 
> 
> I went ahead and used log10() from -lm, everything seems to work
> properly from what I can see. I made a patch with my changes should
> I send that to the linux-kernel mailing list for feedback?

Documentation/process/ is your friend.


Tobin

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Query on mechanisms to communicate between kernel modules in Linux

[Tobin C. Harding]

On Sat, Feb 10, 2018 at 10:30:36PM +0530, Neil Thomas wrote:
> Thanks a lot. I will try out this.

Please don't top post.  It upsets people.

Good luck,
Tobin.

> On 10-Feb-2018 2:08 PM, "Pintu Kumar"  wrote:
> 
> > On Fri, Feb 9, 2018 at 12:52 AM, Neil Thomas  wrote:
> > > Thanks, I will check it out.
> > >
> > > On 09-Feb-2018 12:50 AM,  wrote:
> > >>
> > >> On Thu, 08 Feb 2018 23:38:01 +0530, Neil Thomas said:
> > >>
> > >> > I am just a beginner. I have tried procfs, Netlink socket to
> > communicate
> > >> > between user space and kernel space and it works fine.
> > >> >
> > >> > I am developing a monitoring utility to trace the VFS operation and
> > find
> > >> > the frequency of VFS function calls. This monitoring utility runs in
> > >> > kernel
> > >> > space. We have to record the occurrence of each  VFS function calls
> > >> > (like
> > >> > vfs_open(), vfs_read()).  I don't know  which is best mechanism to
> > >> > report
> > >> > this VFS event to the monitoring utility.
> > >> >
> > >> > Could anyone please suggest the best mechanism to transfer data
> > >> > frequently
> > >> > between kernel modules.
> >
> > You can also use ION (CONFIG_ION) or DMABUF (DMA_SHARED_BUFFER) buffer
> > sharing mechanism to share data between 2 drivers.
> > Check this:
> > https://www.kernel.org/doc/html/latest/driver-api/dma-buf.html
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
> > linux.git/tree/drivers/staging/android/ion?h=v4.15
> >
> > >>
> > >> There's a perfectly good perf-based function trace facility that will
> > >> provide
> > >> this info to userspace.
> > >>
> > >> http://www.brendangregg.com/perf.html#StaticKernelTracing
> > >>
> > >
> > > ___
> > > Kernelnewbies mailing list
> > > Kernelnewbies@kernelnewbies.org
> > > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> > >
> >

> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Documentation bug in kernelnewbies.org/StartKernelHacking

[Tobin C. Harding]

On Wed, Jan 24, 2018 at 09:40:30PM -0500, Christopher Díaz Riveros wrote:
> Hi, I was reading the StartKernelHacking section from kernelnewbies.org
> site and found that the command:
> 
> scripts/checkpatch.pl --terse --show-types --strict path/to/source/file
> 
> needs to add the --file option before path/to..., if not, checkpatch.pl
> will complain about the non-diff format.

fixed. thanks

Tobin

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Help

[Tobin C. Harding]

On Sat, Jan 06, 2018 at 05:44:46PM +0100, Farouk Maâboudallah wrote:
> Good evening everyone :)
> 
> I'm new here with you guys. I have been using Linux for 6 months ... And
> now I'm looking forward to develop and improve my skills.
> I'm a student in digital mechanics which means developing, programming and
> simulating in mechanical engineering. I have C, Matlab and Python as a
> background (another code for simulation like ansys, abaqus, ...). Now, I
> want to learn how to develop linux kernel or something like that ... Any
> helps, any suggestion are welcome :)

Have you done a bunch of userland programming in the Linux environment
during that 6 months? Preferably C systems programming?

Tobin

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Facing problem with mutt for replying or sending mails to linux kernel mailing list

[Tobin C. Harding]

On Sat, Dec 09, 2017 at 11:37:41AM +0530, Pravin Shedage wrote:
> Hi Everyone,
> 
> Sending mail from mutt failed

You can send patches using git

$ git send-email path/to/my.patch

You may need to install separate package (git-email on Ubuntu).

Hope this helps,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

kernel development cycle

[Tobin C. Harding]

Hi,

Would someone please be able to expound on the stages of the kernel
development cycle.

In particular I would like to learn what a hobbyist kernel developer
should be focusing their attention on during different stages of the
cycle. In particular, what _not_ to do during certain stages of the
cycle.

Jonathan Corbet has mentioned that he is happy to take documentation
patches during the merge window. Are other sub-systems open to patches
during the merge window? My guess is not.

Should one be focusing effort on bug fixing only (as opposed to new
features) during rc1 and rc2?

What about coverity fixes, are these most appreciated during early
release candidates or are they better done against linux-next during
later release candidates (so the bugs don't get into the mainline in the
first place)?

When are new feature patches best submitted?

Or is all this not answerable because each maintainer/subsystem is
different?

Thanks in advance for your thoughts,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: git pull

[Tobin C. Harding]

On Tue, Nov 14, 2017 at 12:05:00PM +0100, Greg Kroah-Hartman wrote:
> Adding lkml and linux-doc mailing lists...
> 
> On Tue, Nov 14, 2017 at 10:11:55AM +1100, Tobin C. Harding wrote:
> > Hi Greg,
> > 
> > This is totally asking a favour, feel free to ignore. How do you format
> > your [GIT PULL] emails to Linus? Do you create a tag and then run a git
> > command to get the email?
> > 
> > I tried to do it manually and failed pretty hard (as you no doubt will
> > notice on LKML).
> 
> Well, I think you got it right the third time, so nice job :)

Lucky. Three strikes and your out isn't it?

> Anyway, this actually came up at the kernel summit / maintainer meeting
> a few weeks ago, in that "how do I make a good pull request to Linus" is
> something we need to document.
> 
> Here's what I do, and it seems to work well, so maybe we should turn it
> into the start of the documentation for how to do it.

Patch to come.

> ---
> 
> To start with, put your changes on a branch, hopefully one named in a
> semi-useful way (I use 'char-misc-next' for my char/misc driver patches
> to be merged into linux-next).  That is the branch you wish to tag and
> have Linus pull from.
> 
> Name the tag with something useful that you can understand if you run
> across it in a few weeks, and something that will be "unique".
> Continuing the example of my char-misc tree, for the patches to be sent
> to Linus for the 4.15-rc1 merge window, I would name the tag
> 'char-misc-4.15-rc1':
>   git tag -u KEY_ID -s char-misc-4.15-rc1 char-misc-next
> 
> that will create a signed tag called 'char-misc-4.15-rc1' based on the
> last commit in the char-misc-next branch, and sign it with my gpg key
> KEY_ID (replace KEY_ID with your own gpg key id.)
> 
> When you run the above command, git will drop you into an editor and ask
> you to describe the tag.  In this case, you are describing a pull
> request, so outline what is contained here, why it should be merged, and
> what, if any, testing has happened to it.  All of this information will
> end up in the tag itself, and then in the merge commit that Linus makes,
> so write it up well, as it will be in the kernel tree for forever.
> 
> An example pull request of mine might look like:
>   Char/Misc patches for 4.15-rc1
> 
>   Here is the big char/misc patch set for the 4.15-rc1 merge
>   window.  Contained in here is the normal set of new functions
>   added to all of these crazy drivers, as well as the following
>   brand new subsystems:
>   - time_travel_controller: Finally a set of drivers for
> the latest time travel bus architecture that provides
> i/o to the CPU before it asked for it, allowing
> uninterrupted processing
>   - relativity_shifters: due to the affect that the
> time_travel_controllers have on the overall system,
> there was a need for a new set of relativity shifter
> drivers to accommodate the newly formed black holes
> that would threaten to suck CPUs into them.  This
> subsystem handles this in a way to successfully
> neutralize the problems.  There is a Kconfig option to
> force these to be enabled when needed, so problems
> should not occur.
> 
>   All of these patches have been successfully tested in the latest
>   linux-next releases, and the original problems that it found
>   have all been resolved (apologies to anyone living near Canberra
>   for the lack of the Kconfig options in the earlier versions of
>   the linux-next tree creations.)
> 
>   Signed-off-by: Your-name-here <your_email@domain>
> 
> 
> The tag message format is just like a git commit id.  One line at the
> top for a "summary subject" and be sure to sign-off at the bottom.
> 
> Now that you have a local signed tag, you need to push it up to where it
> can be retrieved by others:
>   git push origin char-misc-4.15-rc1
> pushes the char-misc-4.15-rc1 tag to where the 'origin' repo is located.
> 
> The last thing to do is create the pull request message.  Git handily
> will do this for you with the 'git request-pull' command, but it needs a
> bit of help determining what you want to pull, and what to base the pull
> against (to show the correct changes to be pulled and the diffstat.)
> 
> I use the following command to generate a pull request:
>   git request-pull master 
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ 
> char-misc-4.15-rc1
> 
> This is asking git to compare the differe

git pull

[Tobin C. Harding]

Hi Greg,

This is totally asking a favour, feel free to ignore. How do you format
your [GIT PULL] emails to Linus? Do you create a tag and then run a git
command to get the email?

I tried to do it manually and failed pretty hard (as you no doubt will
notice on LKML).

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Non-web based LXR

[Tobin C. Harding]

On Tue, Oct 31, 2017 at 10:53:58AM +0100, François wrote:
> On Tue, Oct 31, 2017 at 01:14:30PM +1100, Tobin C. Harding wrote:
> > So, thank you for your ideas. I'll consider this issue resolved by;
> > 
> > Use git grep
> > Use ctags/etags
> > Use free-electrons as a last resort
> 
> Also, there's a tool called cscope [1].
> There are also occurences of coccigrep [2] in the kernel.

Cool, thanks François

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Mentors and Archives?

[Tobin C. Harding]

On Tue, Oct 31, 2017 at 12:25:39PM -0400, leam hall wrote:
> Newly back to the list. Is there a way to see if the idea of Kernel-Mentors
> has been talked about recently besides pulling the zip files and grep'ing?
> 
> if no one recalls any discussion; up for it?  :)

If we are going to discuss this I'd like to be on the CC list.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Non-web based LXR

[Tobin C. Harding]

On Tue, Oct 31, 2017 at 08:55:10AM +1100, Tobin C. Harding wrote:
> CC'd Thomas because I read online recently him commenting on web based
> cross reference tools. 
> 
> Hi,
> 
> Does any one use a terminal based source code cross referencer to search
> the kernel tree?
> 
> thanks,
> Tobin.

Responding to all responses in single email. Thanks for the
responses. Apologies, I need to learn to be more explicit when asking
questions to be more respectful of other peoples time.

I already use grep (various versions, git grep, egreg, and ack).

I also already use ctags in emacs (or is it called etags when in emacs).

I [too] often still find myself going to

http://elixir.free-electrons.com

I just attempted to recreate an example search that fails using grep or
ctags but was unable to. Perhaps the problem is a user error, i.e I come
across a code search that is not fully serviced by grep/ctags, go to
free-electros, then go back to it from habit only later realizing that I
am doing so when I get annoyed with having to use a web browser.

So, thank you for your ideas. I'll consider this issue resolved by;

Use git grep
Use ctags/etags
Use free-electrons as a last resort

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

sleep

[Tobin C. Harding]

Is there any 'non-process' context apart from interrupt context? I had a
re-read of sleep sections in ldd3 and in Robert Love's book but am still
not totally clear on this.

The reason for the question is understanding when we cannot sleep.

thanks in advance,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Updating LDD3

[Tobin C. Harding]

On Tue, Oct 24, 2017 at 02:03:59PM +0100, Liam Ryan wrote:
> On Tue, Oct 24, 2017 at 10:49:34AM -0200, Daniel. wrote:
> > You're welcome!
> > 
> > On Oct 24, 2017 10:38 AM, "Ozgur"  wrote:
> > 
> > >
> > > Hello,
> > >
> > > 24.10.2017, 15:31, "Daniel." :
> > >
> > > Here it is https://github.com/martinezjavier/ldd3
> 
> Thanks I had found this repo which is a great reference for when I get
> stuck in my own attempt to update the old code, however I believe this repo 
> is also outdated. For instance it calls aio_complete on line 405 of main.c of 
> scullc which I found has since been removed ( or I made a huge error :) ). 

This is the repo I worked off of

https://github.com/duxing2007/ldd3-examples-3.x

> Leaving that aside I'm referring to updating the book itself rather than the 
> code as the text makes reference to the code as written in 2005.

Isn't that the same thing? You need updated code to update the
book. Not to throw water on your enthusiasm but that book is amazingly
well written, there are [throw away] comments in that book that have
taught me loads about subtle concepts of kernel development.

I would be very hesitant removing any text from that book if one is not
_very_ experienced. There is a wealth of knowledge in it and the few
functions that are out of date do little to reduce it's educational
value IMO.

Sure, it would be nice to have a few of the newer kernel features
included but again this is not a job for just anyone. Those guys that
wrote that book are seriously experienced.

Hope this helps,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: atomic test and set

[Tobin C. Harding]

On Fri, Oct 20, 2017 at 05:33:19PM +0800, Yubin Ruan wrote:
> 2017-10-20 16:55 GMT+08:00 Tobin C. Harding <m...@tobin.cc>:
> > On Fri, Oct 20, 2017 at 10:22:01PM +0800, Yubin Ruan wrote:
> >> On Wed, Oct 18, 2017 at 11:40:44AM +1100, Tobin C. Harding wrote:
> >> > Hi,
> >> >
> >> > Do we have an atomic test and set function in the kernel. I have tried
> >> >
> >> > const int KEY_FLAG_BIT = 1;
> >> >
> >> > ...
> >> >
> >> > static siphash_key_t ptr_secret __read_mostly;
> >> > static unsigned long have_key = 0;
> >> >
> >> > if (test_and_set_bit(KEY_FLAG_BIT, _key))
> >> > get_random_bytes(_secret, sizeof(ptr_secret));
> >> >
> >> >
> >> > But that doesn't work.
> >> >
> >> > I looked in include/linux/atomic.h and thought about using
> >> >
> >> > static atomic_t have_key = ATOMIC_INIT(0);
> >> >
> >> > if (atomic_xchg(_key, 1) == 0)
> >> > get_random_bytes(_secret, sizeof(ptr_secret));
> >> >
> >> >
> >> > This works. My question is; does this code LOAD the value at have_key 
> >> > and STORE the argument on
> >> > every call? Or does it LOAD the value, check if it is the same as the 
> >> > argument, and STORE _only_ if
> >> > it is different?
> >>
> >> Yes it stores at every call. To check before load, you should use cmpxchg
> 
> sorry this should be "check before store" ...
> 
> >>
> >> > (Is this whole discussion just premature optimization?)
> >> >
> >> > I cannot grok the macros in atomic.h, they seem circular. Here is the 
> >> > macro definitions in call
> >> > chain order starting with atomic_xchg()
> >>
> >> I think those macros look loverly ;-)
> >
> > Thanks Yubin, guess I need to work on my macro-foo
> >
> >> Maybe you should look into `Documentation/atomic_ops.txt' for help. Also, I
> >> think see how xchg() and cmpxchg() is implemented in the kernel, e.g., at 
> >> here:
> >>
> >> 
> >> https://elixir.free-electrons.com/linux/latest/source/arch/x86/include/asm/cmpxchg.h
> 
> I really think the `cmpxchg.h' is valuable for learning. Please do
> take a look at it.

I read atomic_ops.txt, thanks. Also I used cmpxchg() like this 

static atomic_t foo = ATOMIC_INIT(0);

...
if (atomic_cmpxchg(, 0, 1) == 0) {
do_this();
}

With the intent that only a single caller will ever call `do_this()`.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: atomic test and set

[Tobin C. Harding]

On Fri, Oct 20, 2017 at 10:22:01PM +0800, Yubin Ruan wrote:
> On Wed, Oct 18, 2017 at 11:40:44AM +1100, Tobin C. Harding wrote:
> > Hi,
> > 
> > Do we have an atomic test and set function in the kernel. I have tried
> > 
> > const int KEY_FLAG_BIT = 1;
> > 
> > ...
> > 
> > static siphash_key_t ptr_secret __read_mostly;
> > static unsigned long have_key = 0;
> > 
> > if (test_and_set_bit(KEY_FLAG_BIT, _key))
> > get_random_bytes(_secret, sizeof(ptr_secret));
> > 
> > 
> > But that doesn't work.
> > 
> > I looked in include/linux/atomic.h and thought about using
> > 
> > static atomic_t have_key = ATOMIC_INIT(0);
> > 
> > if (atomic_xchg(_key, 1) == 0)
> > get_random_bytes(_secret, sizeof(ptr_secret));
> > 
> > 
> > This works. My question is; does this code LOAD the value at have_key and 
> > STORE the argument on
> > every call? Or does it LOAD the value, check if it is the same as the 
> > argument, and STORE _only_ if
> > it is different? 
> 
> Yes it stores at every call. To check before load, you should use cmpxchg
>  
> > (Is this whole discussion just premature optimization?)
> > 
> > I cannot grok the macros in atomic.h, they seem circular. Here is the macro 
> > definitions in call
> > chain order starting with atomic_xchg()
> 
> I think those macros look loverly ;-)

Thanks Yubin, guess I need to work on my macro-foo

> Maybe you should look into `Documentation/atomic_ops.txt' for help. Also, I
> think see how xchg() and cmpxchg() is implemented in the kernel, e.g., at 
> here:
> 
> 
> https://elixir.free-electrons.com/linux/latest/source/arch/x86/include/asm/cmpxchg.h

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: architecture conditional

[Tobin C. Harding]

On Mon, Oct 16, 2017 at 06:10:53PM +0200, Greg KH wrote:
> On Mon, Oct 16, 2017 at 09:37:17PM +1100, Tobin C. Harding wrote:
> > What is the correct way to write code that is conditionally compiled 
> > depending on 32/64 bit?
> 
> Not to write code that is dependent on such a thing in the first place
> :)
> 
> > I found
> > 
> > CONFIG_X86_64
> > CONFIG_64BIT
> > 
> > Do we still support other word sizes?
> 
> No, but those are not what you should be looking for, it all depends on
> the architecture and where in the kernel you need to do this (arch
> specific code, driver, kernel, networking, etc.)
> 
> Any specific hints on why you think you need this?

Hashing the kernel pointers. Wanting to call the SipHash functions. We need to 
call a different
function depending on the size of the pointer.

u64 siphash_1u64(const u64 a, const siphash_key_t *key);
u64 siphash_1u32(const u32 a, const siphash_key_t *key);

Jason A. Donenfeld suggested (offered to) add a helper function in siphash, 
along the lines of
siphash_1u() but we still need to know the exact size of the return value (so 
we can drop half of it
if it is 64 bits). We just want a 32 bit identifier returned after hashing the 
address.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

architecture conditional

[Tobin C. Harding]

What is the correct way to write code that is conditionally compiled depending 
on 32/64 bit?

I found

CONFIG_X86_64
CONFIG_64BIT

Do we still support other word sizes?

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: boot time variable

[Tobin C. Harding]

On Tue, Oct 10, 2017 at 09:08:30AM +0200, Greg KH wrote:
> On Tue, Oct 10, 2017 at 10:17:09AM +1100, Tobin C. Harding wrote:
> > Hi,
> > 
> > I would like to create a boot time variable i.e a variable that is set once 
> > at boot time. Variable
> > does not need to be globally accessible. (actually I am using two 
> > variables).
> 
> static foo = 42;
> 
> should be all you need, right?
> 
> If not, what exactly do you mean by "boot time variable"?
> 
> > Could any one point me to examples of this already intree please?
> > 
> > I have tried the following but it has a race condition on the zero check 
> > and assignment of randval/oddval.
> > 
> > /* Maps a pointer to a unique identifier. */
> > static char *ptr_to_id(char *buf, char *end, void *ptr, struct printf_spec 
> > spec)
> > {
> > long hashval;
> > static long randval = 0;
> > static long oddval = 0;
> > 
> > if (oddval == 0 && randval == 0) {
> > randval = get_random_long();
> > oddval = get_random_odd_long();
> > }
> > 
> > hashval = ptr_obfuscate((unsigned long)ptr, randval, oddval);
> > spec.base = 16;
> > 
> > return number(buf, end, hashval, spec);
> > }
> 
> What's wrong with this code?

Maybe I just have race conditions on the brain.

> > And the compiler doesn't like
> > 
> > static long randval = get_random_long();
> > static long oddval = get_random_odd_long();
> 
> Yeah, that will not work, static initializers are at link/load time, not
> runtime.
> 
> > I thought of wrapping oddval/randval in a struct and protecting it with a 
> > lock but I don't know
> > how/where to initialize the lock in a race free manner?
> 
> Put a local lock in the function when testing if the variables are == 0,
> if you are worried that two different callers will enter it at the same
> time.

Okay.

> hope this helps,
> 
> greg k-h

Cheers Greg

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Xilinx clock wizard driver

[Tobin C. Harding]

On Mon, Oct 09, 2017 at 08:42:34PM -0400, Merin Santhosh wrote:
> Xilinx fpga kits are pretty pricey, doubt if I can buy one.
> Is there any other way these codes can be tested? Can anyone who is an
> expert in the field comment?

Just to let you know. You will get boo'ed loudly on kernel mailing lists if you 
top post (reply to
email above the original email). The preferred method is inline (as this 
comment is). Some people
leave the rest of the email trailing (as I will do on this occasion) and some 
remove everything
after their last comment (as I usually do).

thanks,
Tobin.

> Merin
> 
> Merin Santhosh
> +1 (352) 214-3796
> 
> On Mon, Oct 9, 2017 at 5:46 PM, Tobin C. Harding <m...@tobin.cc> wrote:
> 
> > On Mon, Oct 09, 2017 at 01:16:41PM -0400, Merin Santhosh wrote:
> > > Hi All,
> > >
> > > I'm Merin, I'm a masters student at the University of Florida.
> >
> > Hi Merin, welcome.
> >
> > > I was doing
> > > through the Linux Kernel, hoping to contribute to something of relevance.
> > > Since I have a background in systems, I was hoping to get started with
> > the
> > > Xilinx clocking wizard(link)
> > > <https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/
> > staging.git/tree/drivers/staging/clocking-wizard/TODO>
> >
> > Cool, go for it.
> >
> > > I wanted to know how is it that the modified driver is tested once coded.
> > > Can someone explain to me how this is done?
> >
> > I am by no means an expert. One sure method (for any of the drivers in
> > staging) is to buy some
> > hardware to test the driver. I know nothing about the Xilinx clocking
> > wizard but a quick search
> > shows that you can set up an FPGA board of some sort to use with the
> > clocking wizard. Here is a link
> > you may find useful
> >
> > http://gadgetfactory.net/learn/2017/02/22/fpga-
> > clocking-clocking-wizard-in-xilinx-ise/
> >
> > If you are borking at paying for hardware just look at it as an investment
> > in your education. Any
> > hardware you buy will be cheap compared with your other tuition fees.
> >
> > Happy hacking,
> > Tobin.
> >

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

boot time variable

[Tobin C. Harding]

Hi,

I would like to create a boot time variable i.e a variable that is set once at 
boot time. Variable
does not need to be globally accessible. (actually I am using two variables).

Could any one point me to examples of this already intree please?

I have tried the following but it has a race condition on the zero check and 
assignment of randval/oddval.

/* Maps a pointer to a unique identifier. */
static char *ptr_to_id(char *buf, char *end, void *ptr, struct printf_spec spec)
{
long hashval;
static long randval = 0;
static long oddval = 0;

if (oddval == 0 && randval == 0) {
randval = get_random_long();
oddval = get_random_odd_long();
}

hashval = ptr_obfuscate((unsigned long)ptr, randval, oddval);
spec.base = 16;

return number(buf, end, hashval, spec);
}

And the compiler doesn't like

static long randval = get_random_long();
static long oddval = get_random_odd_long();


I thought of wrapping oddval/randval in a struct and protecting it with a lock 
but I don't know
how/where to initialize the lock in a race free manner?

Any tips or pointers please?

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Xilinx clock wizard driver

[Tobin C. Harding]

On Mon, Oct 09, 2017 at 01:16:41PM -0400, Merin Santhosh wrote:
> Hi All,
> 
> I'm Merin, I'm a masters student at the University of Florida.

Hi Merin, welcome.

> I was doing
> through the Linux Kernel, hoping to contribute to something of relevance.
> Since I have a background in systems, I was hoping to get started with the
> Xilinx clocking wizard(link)
> 

Cool, go for it.

> I wanted to know how is it that the modified driver is tested once coded.
> Can someone explain to me how this is done?

I am by no means an expert. One sure method (for any of the drivers in staging) 
is to buy some
hardware to test the driver. I know nothing about the Xilinx clocking wizard 
but a quick search
shows that you can set up an FPGA board of some sort to use with the clocking 
wizard. Here is a link
you may find useful

http://gadgetfactory.net/learn/2017/02/22/fpga-clocking-clocking-wizard-in-xilinx-ise/

If you are borking at paying for hardware just look at it as an investment in 
your education. Any
hardware you buy will be cheap compared with your other tuition fees.

Happy hacking,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: What all are the drivers those get compiled with the kernel?

[Tobin C. Harding]

On Mon, Sep 11, 2017 at 07:42:42PM -0700, Dipanjan Das wrote:
> There are numerous drivers present in the 'drivers' directory of Linux
> kernel. The kernel source for any Android mobile device [e.g.
> https://android.googlesource.com/kernel/msm/+/android-msm-2.6.35] is, too,
> not an exception. Definitely all the drivers are not relevant for the
> chipset which the mobile device is built on.
> 
> It leads me to believe that *not* all the drivers which are present in the
> kernel source for a mobile device are built and shipped on commercial
> phones. Given the kernel source, how can one figure out what all are the
> drivers those get compiled for that particular mobile device?

One way you could go about this;

If you have a shell on the device you could run `lsmod` to list modules. Then, 
from within a
kernel source tree you can search for files matching the module name

find . -name 'FOO*'

Good luck,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: how to instrument/debug module loading

[Tobin C. Harding]

On Tue, Sep 12, 2017 at 10:49:27AM -0400, Cliff Brake wrote:
> Hi,
> 
> I'm trying to better understand the kernel module loading mechanism
> (for example when you plug in a USB device and a kernel module
> autoloads).  It appears that depmod creates a module.alias map that
> maps USB info to modules.  Is there any way to instrument or observe
> the actual loading process?  I've looking into udev debug logging, and
> udevadm, but have not found anything yet that shows when this device
> is installed, this module loads.

`dmesg` may give you this information.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Don't know where to start linux kernel programming

[Tobin C. Harding]

On Wed, Aug 23, 2017 at 03:57:05PM -0700, Greg KH wrote:
> On Wed, Aug 23, 2017 at 09:06:49PM +0530, Umair Khan wrote:
> > Hi Greg,
> > 
> > On Tue, Aug 22, 2017 at 11:09 PM, Greg KH  wrote:
> > > On Tue, Aug 22, 2017 at 12:59:31PM -0400, valdis.kletni...@vt.edu wrote:
> > >> On Tue, 22 Aug 2017 12:48:42 -0400, Cindy-Sue Causey said:
> > >>
> > >> > An observation that may just mean I haven't stumbled upon it yet is
> > >> > that it would be nice to... stumble upon... a list of kernel problems
> > >> > that *kernelnewbies* could cut their teeth on. I do understand that
> > >> > this is a naive wish list item due to the nearly every nanosecond
> > >> > changing complexity of things. :)
> > >>
> > >> Such a thing existed 10 or 15 years ago.  Unfortunately for the newbies, 
> > >> there
> > >> are very few problems that newbies can attack, because if they were that
> > >> simple, somebody would already have *done* them.
> > >
> > > Not really, please look at drivers/staging/*/TODO there are loads of
> > > simple things left to do, with more being added all the time (a huge new
> > > wireless driver just landed that could use lots of cleanups.)
> > 
> > Which wireless driver exactly?
> 
> The "new" one in the linux-next tree (it's also in the staging-next
> branch of the staging.git tree on git.kernel.org).  Don't remember the
> exact name, it should be easy to find...

looks like it may be drivers/staging/rtlwifi

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Don't know where to start linux kernel programming

[Tobin C. Harding]

On Tue, Aug 22, 2017 at 04:22:34PM +0530, SUNIL KHORWAL wrote:
> Hi,
> I'm new to linux kernel programming, I want to be a linux kernel hacker but
> i don't know where to start.
> Please help me.

I recently wrote some blog posts on this topic. You can check them out at

http://tobin.cc/blog

Greg is correct (as usual), there are loads of things to do in drivers/staging/*

IMHO don't bother venturing far outside of staging for a while, and definitely 
don't submit cleanup
patches to code outside of staging. You can safely get started learning kernel 
dev process patching
staging/*

Good luck,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Don't know where to start linux kernel programming

[Tobin C. Harding]

On Tue, Aug 22, 2017 at 04:45:29PM +0530, SUNIL KHORWAL wrote:
> Thank you very much. :)

Friendly lesson number 1: don't top post when replying to email on a kernel 
mailing list.

> 
> On Tue, Aug 22, 2017 at 4:44 PM, Kamil Konieczny <
> k.koniec...@partner.samsung.com> wrote:
> 
> > Hi,
> >
> > On 22.08.2017 12:52, SUNIL KHORWAL wrote:
> >
> > > I'm new to linux kernel programming, I want to be a linux kernel hacker
> > but
> > > i don't know where to start.
> > > Please help me.
> >
> > Start from https://kernelnewbies.org/
> > https://lwn.net/
> > https://www.kernel.org/
> >
> > You are using gmail, so this may help:
> >
> > linux/Documentation/process/email-clients.rst
> >
> > or
> >
> > http://elixir.free-electrons.com/linux/v4.13-rc6/source/
> > Documentation/process
> > http://elixir.free-electrons.com/linux/v4.13-rc6/source/
> > Documentation/process/email-clients.rst
> >
> > There is eudyptula challange (currently busy, no new subscriptions)
> > and there is note about [not] using gmail for kernel:
> >
> > https://events.linuxfoundation.org/sites/events/files/slides/ec.pdf
> >
> > --
> > Best regards,
> > Kamil Konieczny
> > Samsung R Institute Poland
> >
> >

> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Contribute

[Tobin C. Harding]

On Sat, Jul 22, 2017 at 11:39:45AM +0200, nunojsa wrote:
> Hi all,
> 
> Im fairly new to linux kernel and would like to start with some staging work 
> (seems like the best way to start).
> Basically what i would like to know is which tree should i clone for this? My 
> understanding is that one should never work directly on top of the mainline 
> tree, instead (for this case) on top of the linux staging tree. The same 
> goes, for example, for USB subsystem development in which case i should just 
> clone the usb development tree (and the same for all subsystems).
> 
> Is my understanding correct?

The tree you are after is Greg's staging tree. You can find it here.

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/

As Greg already said, the branch of that tree you want is
staging-next, also you may like to check your patches apply to the
staging-testing branch before submitting them.

Good luck,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: ks7010 cfg80211 re-write

[Tobin C. Harding]

On Fri, Jun 23, 2017 at 10:19:06PM +0800, Greg KH wrote:
> On Thu, Jun 22, 2017 at 11:10:47AM +1000, Tobin C. Harding wrote:
> > May I please ask two questions relating to the correct kernel development
> > protocol to follow for the cfg80211 re-write.
> > 
> > Current state: Functional WEXT driver in drivers/staging.
> > 
> > Interim state: Partial cfg80211 implementation.
> > 
> > Target state: Functional cfg80211 driver in drivers/staging.
> > 
> > Future state: Functional cfg80211 driver out of staging.
> > 
> > Question 1: Is it correct kernel development protocol to do the
> > interim state in public?
> 
> I don't know exactly what you mean by "interm state" here, does the
> driver still work at that point in time?
> 
> The rule is, the driver needs to keep working for every patch submitted
> along the way.  If you are going to have to break that with the rework,
> then no, that's not ok.

Thanks for clarifying Greg.

> I think many many months ago I said that doing this type of conversion
> for a wifi driver was really hard.  It's only ever happened one time in
> the past, and I was amazed at the work involved in doing it.

Yes you did, I did not fully understand you then, I do now.

> Every other time a wifi driver has moved out of staging, the author has
> just given up on the staging driver, and rewritten it "properly" and
> gotten that rewrite merged as one patch, into the real part of the
> kernel, and after that is merged, we delete the staging driver.
> 
> Doing it that way is _much_ easier for the developer, as you don't have
> to deal with any interm state at all, you can tear the thing apart and
> put it back together on your own, and just submit the end result.
> 
> I strongly recommend doing it this way, but it's up to you in the end :)

I will follow your advice. I am not totally clear on the path into the
kernel once I have a re-written functional driver but let's cross that
bridge when we get to it.

> good luck, and I hope this helps,

Yes, thank you, this helps me.

Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: My network device don't work

[Tobin C. Harding]

On Tue, Jun 20, 2017 at 10:12:34PM +0800, Greg KH wrote:
> On Tue, Jun 20, 2017 at 02:32:31PM +0200, wiktoria.lewicka wrote:

Expanding on Greg's response, the document you want to read is

  Documentation/process/coding-style.rst

> > Hello.
> > I write simple network device, but its don't work. Module is loading, 
> > loading, loading...
> > Code:
> > 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #define DEV_NAME "chwdp"
> > 
> > struct net_device my_netdev;
> > 
> > int init_my_net_dev(struct net_device *dev);
> > 
> > struct net_device_ops nops = {
> >   .ndo_init = init_my_net_dev,

Preferred indentation is 8 characters.

> >   //.ndo_uninit = uninit_my_net_dev,

Prefer c89 comments.

> > };
> > 
> > static int __init init_dev(void)
> > {
> >   //my_netdev.netdev_ops = 
> >   int result;
> >   if((netdev_boot_setup_check(_netdev))){
> > printk(KERN_ERR "NETDEV: setup error");
> > return 0;
> 
> Why are you returning success if there was an error?
> 
> And always try to use proper kernel coding style when writing kernel
> code if you expect/want someone else to read it :)

Also, you should run your code through scripts/checkpatch.pl. That
script will catch coding style issues for you and help you learn them.

Good luck,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

network driver tx/rx path buffers

[Tobin C. Harding]

Hi,

I am implementing the rx/tx paths for a network driver.

My current understanding is;

On the tx path the driver processes the sk_buff, producing a
frame, and writes this to the tx buffer.

At interrupt time (given that the device produces interrupts for rx
data received and tx data transmitted) the driver either fills the rx
buffer with the received frame read from the device or empties the tx
buffer and writes the frame to the device.

Once rx data has been written to the buffer the driver should empty the rx
buffer, process the frame and pass it upstairs.

Questions
-

1. Is it ok to process the rx frame in a tasklet or should the tasklet
schedule a work thread to do it so that we are not in software
interrupt context for the entire processing of the frame?

2. Can you us kfifo.h for varying size discreet chunks of data? The
macros in kfifo.h are quite complex for a kernelnewbie, but it seems
that kfifo is better suited to storing fixed size items (i.e stucts)?

3. If the above buffer handling is correct then the data being written
to the rx and tx buffers is of varying size. Is circ_buf.h combined with 
buffer in the device data structure a better option?


For reference, paraphrasing LDD3:

For interrupt driven I/O the input buffer should be filled at
interrupt time and emptied by processes that read the device; the
output buffer should be filled by processes that write to the device
and emptied at interrupt time.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: tx path circular buffer

[Tobin C. Harding]

On Wed, Jun 07, 2017 at 10:48:33AM +0200, Greg KH wrote:
> On Wed, Jun 07, 2017 at 04:03:33PM +1000, Tobin C. Harding wrote:
> > Hi,
> > 
> > I am attempting to implement a circular buffer for the tx path of a
> > networking driver. From my understanding this is something that is
> > very common, yet I am struggling to find a clear way to do it.
> 
> Have you looked at include/linux/kfifo.h?

thanks Greg, I ended up using kfifo for the tx path and circ_buf for
the rx path.

Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

tx path circular buffer

[Tobin C. Harding]

Hi,

I am attempting to implement a circular buffer for the tx path of a
networking driver. From my understanding this is something that is
very common, yet I am struggling to find a clear way to do it.

I have tried to read the source for ath6kl, brcmfmac without
success.

I have read Documentation/circular-buffers.txt and this seems like the
solution however grep'ing drivers/net hints that this is not that
common a way to solve this problem. Also I'm getting in knots with
atomic_t types when copying the text document.

Before I bore you with all my non-working code, does any one please
know, off the top of their heads, a driver with simple-ish / nice clean
implementation that I can learn from?

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: ks7010 firmware upload fail

[Tobin C. Harding]

On Mon, Jun 05, 2017 at 08:07:40PM -0400, Brian Masney wrote:
> On Mon, Jun 05, 2017 at 08:24:44PM +1000, Tobin C. Harding wrote:
> > On Mon, Jun 05, 2017 at 09:22:12AM +0200, Wolfram Sang wrote:
> > > Tobin,
> > > 
> > > > My question is should I be digging further into the MMC code or be doing
> > > > something else with the driver code?
> > > 
> > > So, you haven't found any branch that worked? No plain v4.9 or the
> > > gen3-sdio branch from my tree?
> > 
> > I have not tried cloning your tree. I am using the Rasperry Pi kernel
> > source
> > 
> > https://github.com/raspberrypi/linux
> > 
> > which is v4.9.29
> 
> Hi Tobin,
> 
> Here are some instructions on how to compile an upstream kernel for a
> Raspberry Pi: http://elinux.org/RPi_Upstream_Kernel_Compilation.
> It describes setting up u-boot as the boot loader instead of the
> boot loader that the Raspberry Pi kernel uses. One gotcha to be aware of
> is that the config.txt file on the sd card won't be used.

Thanks Brian.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: ks7010 firmware upload fail

[Tobin C. Harding]

On Mon, Jun 05, 2017 at 09:22:12AM +0200, Wolfram Sang wrote:
> Tobin,
> 
> > My question is should I be digging further into the MMC code or be doing
> > something else with the driver code?
> 
> So, you haven't found any branch that worked? No plain v4.9 or the
> gen3-sdio branch from my tree?

I have not tried cloning your tree. I am using the Rasperry Pi kernel
source

https://github.com/raspberrypi/linux

which is v4.9.29

I checked out the last commit you made to the mainline then cross
compiled the driver from within the Rpi tree, copied the module over
to the Pi and insmod'd it.

To debug I was making code changes on my desktop, re cross compiling
the module and scp'ing it over (then rmmod'ing and insmod'ing the new module).

I'll try using a vanilla 4.9 kernel, and if that fails I'll try cloning your 
tree.

Thanks for getting back to me.

Will report my progress.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

ks7010 firmware upload fail

[Tobin C. Harding]

Hi,

I am attempting to test the ks7010 SIDO Wi-Fi driver (drivers/staging/ks7010/).

Currently probing the driver fails because of a firmware upload error.

I am seeking ideas on where to continue troubleshooting this issue.

Test setup:
- Spectec SDW-823 WIFI card (micro SD).
- Raspberry Pi B 1 (kernel 4.9.29) breakout board connected via GPIO pins.
- Driver code from current mainline (commit 
453e102db531ac1ffa55f3e03c4907c063125859)
  (with additional debugging output calls).

Debugging thus far:

- define DEBUG in ks7010 and mmc makefiles (core, card, host).

kernel messages from time of fail:

[ 3746.903972] mmc1: starting CMD53 arg 94002004 flags 01b5
[ 3746.903985] mmc1: blksz 4 blocks 1 flags 0100 tsac 1000 ms nsac 0
[ 3746.904077] mmc1: req done (CMD53): 0: 1000   
[ 3746.904090] mmc1: 4 bytes transferred: 0
[ 3746.904114] mmc1: starting CMD53 arg 94000804 flags 01b5
[ 3746.904126] mmc1: blksz 4 blocks 1 flags 0100 tsac 1000 ms nsac 0
[ 3746.904180] mmc1: req done (CMD53): 0: 1000   
[ 3746.904189] mmc1: 4 bytes transferred: 0
[ 3746.912784] ks7010_upload_firmware: updated index to: 600
[ 3746.912816] mmc1: starting CMD53 arg 9e80 flags 01b5
[ 3746.912831] mmc1: blksz 512 blocks 128 flags 0100 tsac 1000 ms nsac 0
[ 3746.916336] mmc1: req done (CMD53): 0: 1000   
[ 3746.916353] mmc1: 65536 bytes transferred: 0
[ 3746.916420] ks7010_upload_firmware: wrote to address 1 (DATA_WINDOW) 
65536 bytes
[ 3746.916429] ks7010_sdio_data_compare: read 65536 bytes from address 1
[ 3746.916436] debug messages from mmc/core are enabled
[ 3746.916459] mmc1: starting CMD53 arg 1e80 flags 01b5
[ 3746.916472] mmc1: blksz 512 blocks 128 flags 0200 tsac 1000 ms nsac 0
[ 3746.916575] mmc1: req done (CMD53): 0: 1000   
[ 3746.916588] mmc1: 0 bytes transferred: -84
[ 3746.920029] ks7010_sdio_read: sdio_memcpy_fromio() failed: -84
[ 3746.920100] ks7010: ERROR firmware load failed: 9

Briefly, firmware is uploaded to the card in chunks. Each chunk is
read back from the card to verify the transfer.

CMD53 can be seen to succeed when writing the first chunk to the
card. ks7010_sdio_data_compare() is then called which calls
ks7010_sdio_read() to read back the data written to the card. It is
this call that fails.

(CMD52 appears to be successful as well as CMD53 write).

All function calls (including memory addresses on the card, and kernel
buffer addresses) appear to be correct.

Removing the call to ks7010_sdio_data_compare() leads to an MMC read
error for each successive read (via CMD53) by the driver.

My question is should I be digging further into the MMC code or be doing
something else with the driver code?

Any suggestions, no matter how simple, most appreciated. This is my
first time digging into MMC and my first time really trying to trouble
shoot a kernel issue.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: endian patches

[Tobin C. Harding]

On Mon, May 01, 2017 at 09:39:23AM +0200, Bjørn Mork wrote:
> "Tobin C. Harding" <m...@tobin.cc> writes:
> 
> > Should [drivers/staging/*] patches to endian code be tested on hardware
> > before submission?
> 
> All patches should be tested before submission, IF possible.
> 
> But there is no reason to hold back a patch just because you cannot test
> it yourself.  Submit it anyway, noting the level of testing you have
> done. E.g. "build-tested only", or "verified on LE but not tested on BE",
> or whatever you find appropriate.
> 
> It is not uncommon for the author/submitter to be unable to test bug
> fixes on real hardware.  Many endian fixes will be obvious enough to
> make testing unnessary.  And even if the maintainer thinks testing is
> necessary, there might be reviewers with the necessary hardware but
> without the time or insight to write the code.
> 
> I don't think there ever is a reason not to post a patch.  Just make
> sure that you have done as much as you can to verify it yourself, and
> describe what you have done.  Make it clear if you think it needs more
> testing, and why you haven't done that.  Missing hardware is a very good
> reason.
> 
> > During recent development of ks7010 driver, and from watching patch
> > review on de...@linuxdriverproject.org, I formed the opinion that
> > patches fixing endian issues need to be tested on hardware before they
> > can be *guaranteed* to be correct.
> 
> No patch is *guaranteed* to be correct in my experience :)
> 
> Seriously, I don't think there is anything special about endian fixes.
> Yes, they do add an additional hardware dimension, which often will
> trigger the missing test hardware problem.  But the question about
> whether testing on hardware is necessary or not is the same as for all
> other fixes.  So is the answer: It depends.
> 
> Endian fixes like documenting the hardware registers, and adding
> conversion to and from the CPU endianness when accessing them, will
> often be obvious enough to be applicable even without testing.
> 
> 
> Bjørn

thanks Bjørn

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

endian patches

[Tobin C. Harding]

Should [drivers/staging/*] patches to endian code be tested on hardware
before submission?

During recent development of ks7010 driver, and from watching patch
review on de...@linuxdriverproject.org, I formed the opinion that
patches fixing endian issues need to be tested on hardware before they
can be *guaranteed* to be correct.

Is this opinion well founded?

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: english grammar and patches

[Tobin C. Harding]

On Wed, Apr 26, 2017 at 06:34:39AM +0200, Greg KH wrote:
> On Tue, Apr 25, 2017 at 09:25:26PM -0400, valdis.kletni...@vt.edu wrote:
> > On Wed, 26 Apr 2017 10:27:00 +1000, "Tobin C. Harding" said:
> > > This question relates to English grammar and correct usage when
> > > writing gitlog messages and patch series cover letters.
> > >
> > > The writing of gitlog messages is covered in submitting-patches.rst,
> > > of note is the mood to use. It is not stated but I think it is
> > > a subjunctive description of the problem being addressed followed by
> > > an imperative description of what is being done in the patch. Please
> > > correct me if I am wrong.
> > >
> > > The question is: what mood to use in the cover letter.
> > 
> > Please note that most kernel hackers wouldn't recognize a subjunctive mood
> > if it bit them on the ass.  In addition, we have a large number of people
> > writing code for whom English is a second, or third, or even not well 
> > learned
> > fourth language.
> > 
> > And I'm not even convinced that even if they were able to recognize it,
> > that it would be the correct mood to use.
> > 
> > http://www.dummies.com/education/language-arts/grammar/using-the-subjunctive-mood-in-english/
> 
> I agree with these, and then there is the big fact that some
> maintainers, myself included, just ignore the 00/XX emails and don't
> really read them, as the patches themselves should contain enough
> information to understand what is happening.
> 
> But note, some maintainers really do like them, and do care.  So you
> can't ignore them.  Just do a short summary of what is going to be in
> the patch series, that's all.  No one expects a short essay with correct
> grammer, this shouldn't be a major amount of work to create it, just a
> few sentences saying what the patch series contains is all that is
> needed.

Oh cool, thank you!

Tobin

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

english grammar and patches

[Tobin C. Harding]

This question relates to English grammar and correct usage when
writing gitlog messages and patch series cover letters.

The writing of gitlog messages is covered in submitting-patches.rst,
of note is the mood to use. It is not stated but I think it is
a subjunctive description of the problem being addressed followed by
an imperative description of what is being done in the patch. Please
correct me if I am wrong.

The question is: what mood to use in the cover letter. Also, is the
subject of the cover letter explicit or implicit? Said another way is
it acceptable to say 'this series' within the cover letter? It is
specifically stated not to use the subject within the patch itself,
however, many patch sets on LKML use the subject in the cover letter.

Finally, has anyone, within easy reach, a link to a canonical patch
set cover letter. I have searched LKML but am unable to judge for
myself. I would like to add a link to the kernel newbies wiki also if
one is available.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: What is the fastest way to build and boot a kernel

[Tobin C. Harding]

On Tue, Apr 18, 2017 at 08:59:36AM -0700, Code Soldier1 wrote:
[snip]

Why the moniker?

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Patch Question

[Tobin C. Harding]

On Tue, Apr 18, 2017 at 05:07:08PM -0600, Perry Hooker wrote:
> Thanks for the advice, Tobin - I appreciate the reply.

Please don't top post http://daringfireball.net/2007/07/on_top

I'm not an endian expert so I will not comment on the technical
aspects of the path, I can however, comment on the thread and why you
may not be getting the response you desire.

> In this case, I've already followed your advice - I studied the
> reviewer's comments with a fine-toothed comb (some of his comments
> were flat-out incorrect)

Dan Carpenter is very good at what he dose. I would be hesitant to
ever call him or anyone as experienced 'flat-out incorrect'.

> , and traced the buffer in question back to
> its source. It appears to be holding host-endian data, and it's being
> cast to a little-endian type without an explicit conversion. The patch
> I submitted fixes this by using the kernel-defined byte-order macros.

His initial reply hints that this patch may need testing before it can
be applied - have you tested the patch on real hardware? If so, and it
is correct, re-submit the patch stating so.

> I've reached out to the reviewer both individually and via the mailing
> list, and haven't heard back.

>From the thread, and this is only my opinion, it seems Dan has put
more effort than is required of him already. No one is paid to answer
questions on LKML, they are not required to apply effort to your
problems, anything they do is a gift of their time and should be appreciated.

> It's possible that I'm missing something, but I don't see what.

In your comments you in no way display that you understand exactly
what the code is doing and why it should by changed. Your initial
patch does not have an appropriate changelog message, please read
Documentation/process/submitting-patches.rst (section 2 Describing
your changes).

A more subtle point - you may have more success if you do not put
demands onto people (eg can you explain this..) but rather write out
your understanding of the code explaining why your hold the views you
do. Others can then comment or this, agreeing or disagreeing as the
case may be. People like to help by giving their knowledge, no one
likes doing chores.

> At what point is it appropriate to re-submit the patch?

Once you have reworked the patch, taken into consideration the
reviewers comments, written a changelog describing the code as it is
and why it needs changing, explained the patch fully so that the previous
reviewer and future reviewers can understand that you understand what
is going on. Then it is appropriate to re-submit the patch ([PATCH v2]...).

Again, I am only new around here, these are my opinions based on what
I have seen and read. By no means should they be taken as gospel.

Remember, we are all here to make the kernel better. It's not
personal, it's about the kernel.

I hope this helps, best of luck.

Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Problems with adding a sysfs file

[Tobin C. Harding]

On Mon, Apr 17, 2017 at 02:04:48PM -0700, Abhishek Bhardwaj wrote:
> I used a pr_debug and printk KERN_INFO ,before my original email , to
> verify they weren't being called.

You will have more success on kernel mailing lists if you do not top
post as you have done :)

> On Apr 17, 2017 1:43 PM,  wrote:
> 
> > On Mon, 17 Apr 2017 01:17:08 -0700, Abhishek Bhardwaj said:
> > > I followed this link to add a sysfs file
> > > http://kroah.com/log/blog/2013/06/26/how-to-create-a-
> > sysfs-file-correctly/
> > > .
> > >
> > > I set the driver.groups field and declared the attribute and attribute
> > > groups required by the sysfs file. When I boot my kernel I see the
> > > file but my store and show handlers don't get called when I try to cat
> > > or echo to the file. Is there any step I'm missing ?.
> >
> > The traditional way to start debugging this is to add a line at the
> > beginning
> > of your show and store routines:
> >
> > printk(KERN_DEBUG "Now in our special sysfs show routine\n");

You could have put your response here, that way readers would have a
reference to you comment.

> > and see if it shows up in your dmesg or not.  If not, your routine
> > is probably not being called.  If it is, the problem is in the routine.
> >
> > (You'd be surprised how often people say their routine isn't getting
> > called,
> > when it in fact is, or vice versa..)
> >

Good luck,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Patch Question

[Tobin C. Harding]

On Mon, Apr 17, 2017 at 05:28:46PM -0600, Perry Hooker wrote:
> Hi everyone,
> 
> I recently submitted a patch to the kernel mailing list:
> https://lkml.org/lkml/2017/3/21/712

Link is broken.

> I received some feedback on the patch. After a bit of polite
> back-and-forth, the respondent stopped replying when I asked for more
> information, and I haven't heard anything from the maintainers.

No one *has* to respond to your email.

> Based on my analysis (contained in the thread), I still think the
> patch is correct & appropriate.

Perhaps you just need to rework it a bit as the reviewer suggested?

> What's the best way to determine if this is a good fix or not?
> How should I proceed if the patch is, in fact, a good fix?

If the patch was good it would have probably been picked up.

I have found myself in similar positions. Often, since we are just
beginners, there is some thing about the situation that we do not
fully understand. This lack of understanding leads us to think we are
correct when in fact we are not. Perhaps you could go back over the
reviewers emails and think all around the code being discussed, make
sure you understand every minute detail of what is being done.

I have found reviewers to be unusually patient with us newbies, if you
display that you have put in effort to try and understand their
position most times you will get a response. If you don't perhaps the
fix is not worth bothering with, the kernel is large there are always
more things to work on.

Hope this helps,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: generic memory addresses

[Tobin C. Harding]

On Thu, Apr 06, 2017 at 06:59:02PM +0200, Greg KH wrote:
> On Thu, Apr 06, 2017 at 08:11:34PM +1000, Tobin C. Harding wrote:
> > On Thu, Apr 06, 2017 at 08:08:20AM +0200, Greg KH wrote:
> > > On Thu, Apr 06, 2017 at 10:31:01AM +1000, Tobin C. Harding wrote:
> > > > Why is there code in-tree that declares generic memory addresses as
> > > > unsigned int?
> > > > 
> > > > Linux Device Drivers 3rd Edition page 289
> > > >  Therefore, generic memory addresses in the kernel are usually unsigned
> > > >  long, exploiting the fact that pointers and long integers are always
> > > >  the same size, at least on all the platforms currently supported by
> > > >  Linux.
> > > > 
> > > > It would therefore seem like a bug to declare a generic memory address
> > > > as an unsigned int in code that can run on 64 bit machines.
> > > 
> > > I agree, that does seem like a bug.
> > 
> > The example that started me looking at this is in
> > drivers/mmc/core/sdio_io.c
> > 
> > int sdio_memcpy_fromio(struct sdio_func *func, void *dst,
> > unsigned int addr, int count)
> > {
> > return sdio_io_rw_ext_helper(func, 0, addr, 1, dst, count);
> > }
> > 
> > Is there perhaps some reason that it can be guaranteed that this
> > address is for 32 bit architecture. Is it acceptable to think that mmc
> > cards are never more than 32 bit and this code will never have its use
> > extended to where 64 bit addresses are used?
> 
> How do you know this is a "real" address, and not just an sdio
> "address"?  The two are very different.  See the SDIO spec for details
> about how that protocol works if you are curious.

Ok. I need to learn some more. Thanks for the tip to read the SDIO spec.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: generic memory addresses

[Tobin C. Harding]

On Thu, Apr 06, 2017 at 08:08:20AM +0200, Greg KH wrote:
> On Thu, Apr 06, 2017 at 10:31:01AM +1000, Tobin C. Harding wrote:
> > Why is there code in-tree that declares generic memory addresses as
> > unsigned int?
> > 
> > Linux Device Drivers 3rd Edition page 289
> >  Therefore, generic memory addresses in the kernel are usually unsigned
> >  long, exploiting the fact that pointers and long integers are always
> >  the same size, at least on all the platforms currently supported by
> >  Linux.
> > 
> > It would therefore seem like a bug to declare a generic memory address
> > as an unsigned int in code that can run on 64 bit machines.
> 
> I agree, that does seem like a bug.

The example that started me looking at this is in
drivers/mmc/core/sdio_io.c

int sdio_memcpy_fromio(struct sdio_func *func, void *dst,
unsigned int addr, int count)
{
return sdio_io_rw_ext_helper(func, 0, addr, 1, dst, count);
}

Is there perhaps some reason that it can be guaranteed that this
address is for 32 bit architecture. Is it acceptable to think that mmc
cards are never more than 32 bit and this code will never have its use
extended to where 64 bit addresses are used?

> > What is the explanation for such declarations in the kernel please?
> > 
> > $ cd KERNEL_TREE
> > $ git grep 'unsigned int addr' | wc -l
> > 556
> 
> Make sure those really are being used to store a real address, sometimes
> they are not...

righto.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

generic memory addresses

[Tobin C. Harding]

Why is there code in-tree that declares generic memory addresses as
unsigned int?

Linux Device Drivers 3rd Edition page 289
 Therefore, generic memory addresses in the kernel are usually unsigned
 long, exploiting the fact that pointers and long integers are always
 the same size, at least on all the platforms currently supported by
 Linux.

It would therefore seem like a bug to declare a generic memory address
as an unsigned int in code that can run on 64 bit machines.

What is the explanation for such declarations in the kernel please?

$ cd KERNEL_TREE
$ git grep 'unsigned int addr' | wc -l
556

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [0] vs array

[Tobin C. Harding]

On Thu, Mar 30, 2017 at 04:05:51PM +, Nicholas Mc Guire wrote:
> On Thu, Mar 30, 2017 at 09:04:35AM -0400, Ruben Safir wrote:
> > On 03/29/2017 08:30 PM, Tobin C. Harding wrote:
> > > Does the kernel community have a preference when using the address of
> > > the first element of an an array?
> > > 
> > > 1. addr = [0]
> > > 2. addr = array;
> > > 
> > > $ grep '\&.*\[0\]' | wc -l
> > > 10077
> > > 
> > > style (1) is clearly used, I was not able to grep for instances where
> > > style (2) is used.
> > 
> > maybe there is a another reason why 2 is not used.
> >
> the second form is used - just not quite as often  
> with the below quick (and probably incomplete) coccinelle script you 
> can find a few hundred occurences of the second form in linux-next 
> 
> 
> virtual report
> 
> @v2@
> identifier array,addr;
> type T;
> position p;
> @@
> 
> (
> * T array[];
> |
> * T array[] = ...;
> )
>  ...
> * addr = array@p
>  
> @script:python@
> p << v2.p;
> @@
> print "%s:%s" % (p[0].file,p[0].line)
> 
> 
> If its really obvious that its an array that you are manipulating
> maybe the second version is fine - if its not so obvious the
> first version makes it clear - and as readability is a key issue
> for any complex code I suspect that readability explains the preference.

Got it, readability over brevity.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: patch splitting

[Tobin C. Harding]

On Wed, Mar 29, 2017 at 08:55:02PM -0400, valdis.kletni...@vt.edu wrote:
> On Thu, 30 Mar 2017 11:22:40 +1100, "Tobin C. Harding" said:
> > Is it easier to review this change for correctness if it is three
> > patches or one?
> >
> > TLDR;
> > +   struct wpa_key_t *key = >wpa.key[index];
> >
> > -   memcpy(>wpa.key[index].rx_seq[0], enc->rx_seq, 
> > IW_ENCODE_SEQ_MAX_SIZE);
> > +   memcpy(key->rx_seq, enc->rx_seq, IW_ENCODE_SEQ_MAX_SIZE);
> 
> One patch for one thing.
> 
> > Brief description of steps:
> > 1. Add local pointer variable, defined to correct memory location.
> > 2. Use newly defined local variable where suitable.
> > 3. Remove unnecessary address operator (reasoning specified below).
> 
> So, is this 3 things?  Or one thing:
> 
> "Simplify overly-complex first argument to memcpy()"?


Thanks Valdis, very well explained.

Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[0] vs array

[Tobin C. Harding]

Does the kernel community have a preference when using the address of
the first element of an an array?

1. addr = [0]
2. addr = array;

$ grep '\&.*\[0\]' | wc -l
10077

style (1) is clearly used, I was not able to grep for instances where
style (2) is used.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

patch splitting

[Tobin C. Harding]

Is it easier to review this change for correctness if it is three
patches or one?

TLDR;
+   struct wpa_key_t *key = >wpa.key[index];

-   memcpy(>wpa.key[index].rx_seq[0], enc->rx_seq, 
IW_ENCODE_SEQ_MAX_SIZE);
+   memcpy(key->rx_seq, enc->rx_seq, IW_ENCODE_SEQ_MAX_SIZE);   





Brief description of steps:
1. Add local pointer variable, defined to correct memory location.
2. Use newly defined local variable where suitable.
3. Remove unnecessary address operator (reasoning specified below).

Extended description of steps:

1. Add local variable (defined in one statement here for brevity)

struct wpa_key_t *key = >wpa.key[index];

2. Use newly defined local variable where suitable.

sample original code

...
} else if (enc->ext_flags & IW_ENCODE_EXT_RX_SEQ_VALID) {
   memcpy(>wpa.key[index].rx_seq[0],
   enc->rx_seq, IW_ENCODE_SEQ_MAX_SIZE);
   ...

sample code after step 2:
...
} else if (enc->ext_flags & IW_ENCODE_EXT_RX_SEQ_VALID) {
   memcpy(>rx_seq[0], enc->rx_seq, IW_ENCODE_SEQ_MAX_SIZE);
   ...

Justification for step 3:

In the above call to memcpy() taking the address of the initial
element of the array adds no extra information to the call since the
source variable is named identically and does not take the address of
the first element.

sample final state:
...
} else if (enc->ext_flags & IW_ENCODE_EXT_RX_SEQ_VALID) {
   memcpy(key->rx_seq, enc->rx_seq, IW_ENCODE_SEQ_MAX_SIZE);
   ...

thanks for taking the time to read.

Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

0 bit shift

[Tobin C. Harding]

What is the reason for the zero bit shift in this code please?

#define SDIO_STATE_PRESENT  (1<<0)  /* present in sysfs */

file: include/linux/mmc/sdio_func.h

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

edit wiki

[Tobin C. Harding]

Hi Rik,

Could you please add me to the list of names for editing the
kernelnewbies wiki.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

edit wiki

[Tobin C. Harding]

Could someone please add me to the list of names for editing the
kernelnewbies wiki.

>From https://kernelnewbies.org/

To prevent wiki spam, only users on this list are allowed to edit the
wiki. Any of these users can add new usernames to the list. If you
need to be on the list, please ask in #kernelnewbies on irc.oftc.net
or on the mailing list.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: My kernel patch was rejected with comments

[Tobin C. Harding]

On Wed, Mar 22, 2017 at 12:24:47PM +0530, Prasant J wrote:
> Hi,
> 
> I submitted a kernel patch and it was rejected with comments from
> maintainer. Is it important to reply with a new patch against
> maintainers response mail? Or it it ok if I send a new email with the
> updated patch?

You don't send the new patch as a reply. You may, if you wish, reply
to the maintainer (or reviewer) with some comments that you understand
and intend on implementing their suggestions (and thanks) or
disagreeing as it may be.

You then re-work your patch and submit it as normal using git
send-email. But you put v2 in the subject.  You can use

git format-patch -X --subject-prefix='PATCH v2' --numbered --cover-letter

(where X is the number of commits to add to the series, assuming it is
a series).

In the cover letter add a section stating the changes since v1, for
example

v1 -> v2
 - use foo() instead of bar()

If it is a single patch, you may wish to just edit the subject
manually. Make sure you put the version change information below the
--- line so it is not included if/when the patch gets merged.

Good luck,
Tobin.

> 
> 
> I have mutt and git send-mail setup but I can only send mail with
> those. How do I reply to a maintainers comment?
> 
> 
> I manually copied Message-ID from gmail web GUI and tried using it in
> "--in-reply-to" with git send email but when I saw the linux mailing
> list, it did weird things. It sent a blank reply to maintainers email
> and sent a new mail with my updated patch.
> 
> 
> Is there any tutorial on how can a I setup my workflow?
> 
> 
> Any inputs will be of great help here!
> 
> 
> Regards, Pj
> 
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: pr_debug

[Tobin C. Harding]

On Thu, Mar 16, 2017 at 01:17:42PM +0200, Alexander Kapshuk wrote:
> On Wed, Mar 15, 2017 at 11:15 PM, Tobin C. Harding <m...@tobin.cc> wrote:
> > On Wed, Mar 15, 2017 at 12:12:48PM +0100, Bjørn Mork wrote:
> >> Alexander Kapshuk <alexander.kaps...@gmail.com> writes:
> >>
> >> >>> On Wed, Mar 15, 2017 at 10:31 AM, Tobin C. Harding <m...@tobin.cc> 
> >> >>> wrote:
> >> >>> > why does calling pr_debug() with more than one argument cause a 
> >> >>> > sparse
> >> >>> > warning?
> >> >>> >
> >> >>> > drivers/mmc/core/sdio_io.c:70:9: error: unknown field name in 
> >> >>> > initializer
> >> >>> >
> >> >>> > sdio_io.c:70:
> >> >>> > pr_debug("SDIO: Enabling device %s...\n", sdio_func_id(func));
> >> ..
> >> > 'sdio_func_id()' is a macro defined here:
> >> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/linux/mmc/sdio_func.h?id=refs/tags/v4.11-rc2
> >> > #define sdio_func_id(f) (dev_name(&(f)->dev))
> >>
> >>
> >> So the "func" in that debug call contains a 'struct device'.  Any
> >> reason why the pr_debug() shouldn't be converted to something like
> >>
> >>  dev_dbg(>dev, "SDIO: Enabling device...\n");
> >
> > Good point Bjørn, thanks. And thank you Alexander for your input. I
> > fear I may have sent you both on a wild goose chase with the example
> > that I chose. pr_debug() causes a sparse warning in many instances
> > when the format string includes format specifiers.
> >
> > /* this is fine */
> > pr_debug("some info string");
> >
> > /* this often causes Sparse warning */
> > pr_debug("string with specifier: %d", foo);
> >
> > A simple example can be seen by adding this function
> >
> > void foo(const char *baz)
> > {
> > pr_debug("cause Sparse warning - %s\n", baz);
> > }
> >
> > To a random driver, and running `make C=2 M=drivers/staging/ks7010`
> >
> > drivers/staging/ks7010/ks_hostif.c:2702:9: error: unknown field name in 
> > initializer
> >
> > For more examples from the kernel tree, running:
> > $ make -j9 C=2 M=drivers/staging 2>sparse.out
> >
> > gives many such cases, for example:
> >
> > drivers/staging/fbtft/fbtft-core.c:472:17: error: unknown field name in 
> > initialize
> > drivers/staging/media/bcm2048/radio-bcm2048.c:2596:17: error: unknown field 
> > name in initializer
> > drivers/staging/dgnc/dgnc_tty.c:1274:17: error: unknown field name in 
> > initializer
> >
> > Also dev_debug causes the same sparse warning at times, for example:
> >
> > drivers/staging/comedi/comedi_fops.c:352:17: error: unknown field name in 
> > initialize
> >
> > if (s->busy) {
> > dev_dbg(dev->class_dev,
> > "subdevice is busy, cannot resize buffer\n");
> > return -EBUSY;
> > }
> >
> > And 2 more example instances of dev_debug:
> > drivers/staging/comedi/drivers/das16.c:578:25: error: unknown field name in 
> > initialize
> > drivers/staging/dgnc/dgnc_tty.c:1274:17: error: unknown field name in 
> > initializer
> >
> > thanks,
> > Tobin.
> 
> The pr_debug() manpage, https://www.kernel.org/doc/local/pr_debug.txt,
> states that:
> 
> Some files call pr_debug(), which is ordinarily an empty macro that discards
> its arguments at compile time.  To enable debugging output, build the
> appropriate file with -DDEBUG by adding
> 
>   CFLAGS_[filename].o := -DDEBUG
> 
> to the makefile.
> 
> You did not mention whether you have compiling those modules with the
> DEBUG flag enabled, so, perhaps if you didn't, that could be the
> reason why you've been getting those errors.

Nice suggestion, thanks. I have DEBUG enabled.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: pr_debug

[Tobin C. Harding]

On Wed, Mar 15, 2017 at 12:12:48PM +0100, Bjørn Mork wrote:
> Alexander Kapshuk <alexander.kaps...@gmail.com> writes:
> 
> >>> On Wed, Mar 15, 2017 at 10:31 AM, Tobin C. Harding <m...@tobin.cc> wrote:
> >>> > why does calling pr_debug() with more than one argument cause a sparse
> >>> > warning?
> >>> >
> >>> > drivers/mmc/core/sdio_io.c:70:9: error: unknown field name in 
> >>> > initializer
> >>> >
> >>> > sdio_io.c:70:
> >>> > pr_debug("SDIO: Enabling device %s...\n", sdio_func_id(func));
> ..
> > 'sdio_func_id()' is a macro defined here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/linux/mmc/sdio_func.h?id=refs/tags/v4.11-rc2
> > #define sdio_func_id(f) (dev_name(&(f)->dev))
> 
> 
> So the "func" in that debug call contains a 'struct device'.  Any
> reason why the pr_debug() shouldn't be converted to something like
> 
>  dev_dbg(>dev, "SDIO: Enabling device...\n");

Good point Bjørn, thanks. And thank you Alexander for your input. I
fear I may have sent you both on a wild goose chase with the example
that I chose. pr_debug() causes a sparse warning in many instances
when the format string includes format specifiers.

/* this is fine */
pr_debug("some info string");   

/* this often causes Sparse warning */
pr_debug("string with specifier: %d", foo); 

A simple example can be seen by adding this function

void foo(const char *baz)
{
pr_debug("cause Sparse warning - %s\n", baz);
}

To a random driver, and running `make C=2 M=drivers/staging/ks7010`

drivers/staging/ks7010/ks_hostif.c:2702:9: error: unknown field name in 
initializer

For more examples from the kernel tree, running:
$ make -j9 C=2 M=drivers/staging 2>sparse.out

gives many such cases, for example:

drivers/staging/fbtft/fbtft-core.c:472:17: error: unknown field name in 
initialize
drivers/staging/media/bcm2048/radio-bcm2048.c:2596:17: error: unknown field 
name in initializer
drivers/staging/dgnc/dgnc_tty.c:1274:17: error: unknown field name in 
initializer

Also dev_debug causes the same sparse warning at times, for example:

drivers/staging/comedi/comedi_fops.c:352:17: error: unknown field name in 
initialize

if (s->busy) {
dev_dbg(dev->class_dev,
"subdevice is busy, cannot resize buffer\n");
return -EBUSY;
}

And 2 more example instances of dev_debug:
drivers/staging/comedi/drivers/das16.c:578:25: error: unknown field name in 
initialize
drivers/staging/dgnc/dgnc_tty.c:1274:17: error: unknown field name in 
initializer

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: pr_debug

[Tobin C. Harding]

On Wed, Mar 15, 2017 at 12:01:39PM +0200, Alexander Kapshuk wrote:
> On Wed, Mar 15, 2017 at 10:31 AM, Tobin C. Harding <m...@tobin.cc> wrote:
> > why does calling pr_debug() with more than one argument cause a sparse
> > warning?
> >
> > drivers/mmc/core/sdio_io.c:70:9: error: unknown field name in initializer
> >
> > sdio_io.c:70:
> > pr_debug("SDIO: Enabling device %s...\n", sdio_func_id(func));
> >
> > What can we do about this?
> >
> > thanks,
> > Tobin.
> >
> > ___
> > Kernelnewbies mailing list
> > Kernelnewbies@kernelnewbies.org
> > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 
> What is the version of the sources you are using?

I'm usually working of gregKH's staging tree using branch staging-next
and/or staging-testing

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

pr_debug

[Tobin C. Harding]

why does calling pr_debug() with more than one argument cause a sparse
warning?

drivers/mmc/core/sdio_io.c:70:9: error: unknown field name in initializer

sdio_io.c:70:
pr_debug("SDIO: Enabling device %s...\n", sdio_func_id(func));

What can we do about this?

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

driver dev mailing lists

[Tobin C. Harding]

What is the difference between these two mailing lists please?

1) de...@driverdev.osuosl.org
2) de...@linuxdriverproject.org

drivers/staging/ks7010/TODO asks for patches to be sent to
the second but scritps/get_maintainer.pl directs
patches towards the first.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: coccinelle

[Tobin C. Harding]

On Tue, Mar 14, 2017 at 08:52:02AM +0100, Peter Senna Tschudin wrote:
> I guess this is off topic on this list. There is an specific
> Coccinelle mailing list:
> 
> https://systeme.lip6.fr/mailman/listinfo/cocci

Noted, thank you.

Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: coccinelle

[Tobin C. Harding]

On Tue, Mar 14, 2017 at 08:26:08AM +, Nicholas Mc Guire wrote:
> On Tue, Mar 14, 2017 at 06:21:06PM +1100, Tobin C. Harding wrote:
> > Attempting to do transform using Coccinelle
> > 
> > if (foo != 0) {
> >...
> > 
> > ->
> > 
> > if (foo) {
> >...
> > 
> > Coccinelle script attempt does not work
> > 
> > @@ expression x; @@
> > (
> > - x != 0
> > + x
> > )
> 
> I think you do not need the () here as you only are providing one semanntic 
> patch
> the only thing that was missing is the virtual rule - so using this simple 
> spatch
> file works for me 
> 
> 
> virtual patch
> 
> @tonull@
> expression x;
> @@
> 
> - x != 0
> + x
> 
> 
> hofrat@debian01:~/git/linux-next$ spatch --sp-file x.cocci --dir kernel/ | 
> more
> init_defs_builtins: /usr/local/lib/coccinelle/standard.h
> no inferred keywords
> HANDLING: kernel/sched/cpudeadline.c
> diff = 
> HANDLING: kernel/sched/swait.c
> diff -u -p a/sched/cpudeadline.c b/sched/cpudeadline.c
> --- a/sched/cpudeadline.c
> +++ b/sched/cpudeadline.c
> @@ -80,7 +80,7 @@ static void cpudl_heapify_up(struct cpud
> int orig_cpu = cp->elements[idx].cpu;
> u64 orig_dl = cp->elements[idx].dl;
>  
> -   if (idx == 0)
> +   if (!idx)
> return;
> 
> 
> 
> > 
> > `spatch --parse-cocci script.cocci` appears to pass. A similar script
> > worked correctly
> > 
> > @@ expression x; @@
> > (
> > - x == 0
> > + !x
> > )
> 
> likewise
> 
> 
> virtual patch
> 
> @tontnull@
> expression x;
> @@
> 
> - x == 0
> + !x
> 
> 
> Using: spatch --version
> spatch version 1.0.6-00033-g23cca0a compiled with OCaml version 4.0
> .0
> Flags passed to the configure script: [none]
> Python scripting support: yes
> Syntax of regular expresssions: PCRE
> 
> 
> > 
> > I have read various papers and tutorials to no avail. I have tried
> > various other versions also with no success.
> > 
> > Any pointers most appreciated.
> >
> first you might want to read through the myriads of examples that
> come with coccinelle in the kernel:
> scripts/coccinelle/*
> Documentation/dev-tools/coccinelle.rst
> 
> as well as the documentation in coccinelle repository:
> URL: https://github.com/coccinelle/coccinelle 
> 
> And for specific technologies like semantic patches it is best to signeup
> to the coccinelle mailing list and send such questions to
>  co...@systeme.lip6.fr
> archive at: https://systeme.lip6.fr/mailman/listinfo/cocci
> 
> thx!
> hofrat

thanks Hofrat, awesome.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

standard error codes

[Tobin C. Harding]

Driver code in staging/drivers/ks7010 uses the error code -E2BIG as
the error returned if a string argument is larger than destination
buffer. Would this not be better suited to the error code -EOVERFLOW?
Does it matter?

For reference;

#define E2BIG7  /* Argument list too long */
#define EOVERFLOW   75  /* Value too large for defined data type */

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: return codes

[Tobin C. Harding]

On Tue, Mar 14, 2017 at 10:08:51AM +0800, Greg KH wrote:
> On Tue, Mar 14, 2017 at 01:03:07PM +1100, Tobin C. Harding wrote:
> > On investigating call sites for 'return' in drivers/staging/ks7010/
> > it can be seen that a number of functions us *custom* (positive)
> > integers to indicate error. Notwithstanding that they are positive, is
> > this ok for code in the kernel (i.e in order to get out of staging
> > does this need to be changed)? Functions in question have internal linkage
> > and the error code is used for debug messages.
> > 
> > Should these be
> > 
> > A) left alone
> > B) made negative
> > C) changed to use standard error codes (i.e -ENOMEM etc)
> 
> C) please

Awesome.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

return codes

[Tobin C. Harding]

On investigating call sites for 'return' in drivers/staging/ks7010/
it can be seen that a number of functions us *custom* (positive)
integers to indicate error. Notwithstanding that they are positive, is
this ok for code in the kernel (i.e in order to get out of staging
does this need to be changed)? Functions in question have internal linkage
and the error code is used for debug messages.

Should these be

A) left alone
B) made negative
C) changed to use standard error codes (i.e -ENOMEM etc)

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: diff

[Tobin C. Harding]

On Mon, Mar 13, 2017 at 07:43:00AM +, Nicholas Mc Guire wrote:
> On Mon, Mar 13, 2017 at 05:57:14PM +1100, Tobin C. Harding wrote:
> > On occasions diff output does not render the same as it does when
> > editing a file. For example, while removing checkpatch tab warning
> > the following diff was generated
> > 
> > -#define KS_WLAN_SET_WPS_ENABLE SIOCIWFIRSTPRIV + 4
> > -#define KS_WLAN_GET_WPS_ENABLE SIOCIWFIRSTPRIV + 5
> > +#define KS_WLAN_SET_WPS_ENABLE SIOCIWFIRSTPRIV + 4
> > +#define KS_WLAN_GET_WPS_ENABLE SIOCIWFIRSTPRIV + 5
> > 
> > However when editing the file the alignment was not changed, just tabs
> > were inserted instead of spaces.
> 
> if the removed lines were using tabs which they should then they are
> moved by the inserted "-" while the added lines were using spaces
> and thus did not "jump" to the next tabstop.
> 
> > 
> > I had the same thing happen a few days ago (reproduced here from
> > memory)
> > 
> > -static void foo(struct bar *barp, struct baz *bazp)
> > +static void foo(struct bar *barp,
> > +   struct baz *bazp)
> > {
> > ...
> > 
> > When editing the file the two s's in struct were aligned but not in
> > the diff output. I reapplied this patch to a clean tree and it applied
> > correctly.
> 
> this is simply because the insertion is by tabs so when diff added the
> +/- output it moved the "static void foo..." but not the "struct baz"
> so this looks unaligned in the diff output while it actually is aligned
> properly.
> 
> > 
> > How do maintainers visually parse this if the output is not identical in the
> > diff and the file once applied?
> >
> checkpatch will warn if spaces were used and if its based on tabs
> I guess most can see if aligment is correct or not.

Nice explanation, thank you.

Regards,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

diff

[Tobin C. Harding]

On occasions diff output does not render the same as it does when
editing a file. For example, while removing checkpatch tab warning
the following diff was generated

-#define KS_WLAN_SET_WPS_ENABLE SIOCIWFIRSTPRIV + 4
-#define KS_WLAN_GET_WPS_ENABLE SIOCIWFIRSTPRIV + 5
+#define KS_WLAN_SET_WPS_ENABLE SIOCIWFIRSTPRIV + 4
+#define KS_WLAN_GET_WPS_ENABLE SIOCIWFIRSTPRIV + 5

However when editing the file the alignment was not changed, just tabs
were inserted instead of spaces.

I had the same thing happen a few days ago (reproduced here from
memory)

-static void foo(struct bar *barp, struct baz *bazp)
+static void foo(struct bar *barp,
+   struct baz *bazp)
{
...

When editing the file the two s's in struct were aligned but not in
the diff output. I reapplied this patch to a clean tree and it applied
correctly.

How do maintainers visually parse this if the output is not identical in the
diff and the file once applied?

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: cannot insmod sculld in ldd3

[Tobin C. Harding]

On Fri, Mar 10, 2017 at 08:19:29PM +0330, Ali Aminian wrote:
> Hello
> when i try to insmod sculld insmod prints this error message:
> insmod: ERROR: could not insert module ./sculld.ko: Invalid parameters

What source code are you using. The is a port here

https://github.com/duxing2007/ldd3-examples-3.x

porting ldd3 source to modern kernels.

thanks,
Tobin.

> 
> i checked dmsg and it says:
> [12073.858764] sculld: no symbol version for unregister_ldd_driver
> [12073.858767] sculld: Unknown symbol unregister_ldd_driver (err -22)
> [12073.858780] sculld: no symbol version for register_ldd_device
> [12073.858781] sculld: Unknown symbol register_ldd_device (err -22)
> [12073.858789] sculld: no symbol version for unregister_ldd_device
> [12073.858790] sculld: Unknown symbol unregister_ldd_device (err -22)
> [12073.858794] sculld: no symbol version for register_ldd_driver
> [12073.858795] sculld: Unknown symbol register_ldd_driver (err -22)
> 
> these functions are defined in lddbus and i have insmod lddbus.
> 
> can anyone tell me what is wrong.
> thank you.
> 
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

-- 
Tobin Harding
http://tobin.cc

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: patch protocol question

[Tobin C. Harding]

On Wed, Mar 08, 2017 at 12:12:50AM +0100, Peter Senna Tschudin wrote:
> On Tue, Mar 7, 2017 at 10:29 PM, Tobin C. Harding <m...@tobin.cc> wrote:
> > I would like to know the correct protocol in order to make the
> > maintainers job as easy as possible please.
> >
> > Once a patch has been reviewed and the review makes good points that
> > mean the patch is invalid/unnecessary what is the protocol from then?
> 
> I usually go for a beer when a patch I sent is not needed(two if my
> patch breaks something). If you agree that your patch is not needed,
> this is the end.
> 
> > Assuming one replies to the reviewer with thanks and acknowledging
> > their points. Is it then protocol to state that you are not going to
> > pursue the patch further? How do maintainers know to not bother any
> > more with a patch?
> 
> There is no universal rule that covers all cases, but in general if a
> maintainer states that a patch is not needed, this is the end. Unless
> someone(can be you) makes a point that clarifies the need for your
> patch. In the later case the discussion will make it clear what to do
> next.
> 
> >
> > Similar question; if the last patch of a patch series is not needed
> > should one resend another version without the last patch or is there
> > an accepted protocol to signal this so that the maintainer only looks
> > at merging the initial patches in the series.
> 
> It is easier for the maintainer to let his/her automation to take care
> of the entire series. So the extra work you are going to have to
> re-send will save the maintainer some work, so resend the series if
> one of the patches are not needed. Exception here is if the maintainer
> asks you to do differently.

Got it.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

sizeof

[Tobin C. Harding]

Question relating to the validity/usefulness of patching calls to sizeof.

>From Documentation/process/coding-style.rst

The preferred form for passing a size of a struct is the following:

.. code-block:: c

p = kmalloc(sizeof(*p), ...);

The alternative form where struct name is spelled out hurts readability and
introduces an opportunity for a bug when the pointer variable type is changed
but the corresponding sizeof that is passed to a memory allocator is not.Is the 
distinction between 


 Question:

Is a the following a valid/useful patch or just code churn

diff--

- sizeof(struct foo)
+ sizeof(*fp)

---

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

patch protocol question

[Tobin C. Harding]

I would like to know the correct protocol in order to make the
maintainers job as easy as possible please. 

Once a patch has been reviewed and the review makes good points that
mean the patch is invalid/unnecessary what is the protocol from then?
Assuming one replies to the reviewer with thanks and acknowledging
their points. Is it then protocol to state that you are not going to
pursue the patch further? How do maintainers know to not bother any
more with a patch?

Similar question; if the last patch of a patch series is not needed
should one resend another version without the last patch or is there
an accepted protocol to signal this so that the maintainer only looks
at merging the initial patches in the series.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

log file created by git send-email?

[Tobin C. Harding]

Is there a log of emails sent using `git send-email`? The man page
does not mention one and web search on 'log' returns commands related
(unsurprisingly) to `git log`.

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies