from:"Robert P. J. Day"

Re: Earlier Linux Code...

2023-05-26 Thread Robert P. J. Day

On Fri, 26 May 2023, Deepak Goel wrote:

> Hello
> I am a newbie.
>
> Is it possible to find the linux code of earlier versions like
> 0.1,0.2,...1.0, 1.1...?
>
> Please advise. Thank you.

  I'm confused ... recently, you were asking people on this list to
spoon-feed you the most basic fundamentals of *modern* Linux; now,
you're suddenly interested in versions that are more than 30 years old
and have absolutely no value beyond being historical curiosities.

  What value do you plan on getting out of examining Linux 0.99? How
do you think this will enable you to get a handle on modern Linux,
with its plethora of drivers for devices that did not even exist back
then?

  As before, a simple online search would have told you where to look.
I'm starting to think this entire list is being trolled.

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

Re: Starting to learn Linux...

2023-05-19 Thread Robert P. J. Day

On Fri, 19 May 2023, Deepak Goel wrote:

> Will buy a book. Thank you. Debugging the whole source code of
> Linux, might be a bit tricky at the beginning. Will try ChatGPT.

  Respectfully, you are completely missing the point of this mailing
list. You started by asking for a list of programs that run on Linux;
when that was provided, you changed your mind entirely and insisted
that you wanted to know more about Linux internals like device drivers
and memory management and so on. Now you're suggesting you will
(finally?) buy a book and will further consult ChatGPT.

  Nowhere here have you demonstrated that you've actually put in any
effort of your own to start learning. Your entire approach seems to
be, "Could everyone drop what they're doing and teach me all about
Linux?" One starts to suspect you haven't even installed Linux to
start using it.

  This mailing list is for *kernel* newbies -- people starting to play
with the kernel and who have *specific* questions about something
they're trying. You, on the other hand, are asking to be spoon-fed the
most basic information about simply *running* Linux. You need to go
and invest some effort in learning the simplest things about Linux,
and not ask others to do that for you.

rday

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

Re: A blog for kernel development

2022-03-11 Thread Robert P. J. Day

On Fri, 11 Mar 2022, Amit Kumar wrote:

> Hi,

> Thank you for your replies. I am just laying the foundation. After a
> couple of weeks, I will start posing about the Linux kernel on my
> blog. I am also planning to give online Linux kernel training after
> some time. This might be free. So, keep in touch.
>
> Regards,
> Amit Kumar

  with all due respect, you've been posting about your promises to
start learning linux kernel development and write about it for many
months now, and while you've produced nothing in terms of actual blog
content, you continue to recommend that people follow you and check
out your blog and so on.

  from back in july of last year
(https://www.spinics.net/lists/newbies/msg63239.html), you wrote:

  "Hi All,

  I am just here to inform that I am trying to learn Linux kernel
  development. If someone wants to follow me, so that he may also
  learn with me."

so it's been nine months now, and there is no indication that you have
written or learned *anything* about linux kernel programming, yet you
continue to encourage members of this list to keep visiting your blog,
and you even suggest that you might offer online linux kernel
training, despite no indication that you know the slightest thing
about it.

  it's great that someone wants to get into LKP, and that should
always be encouraged, but what you're doing seems little more than
shameless self-promotion.

rday

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

Re: LDD 3rd ed. - It was: Re: read() via USB bus

2021-08-12 Thread Robert P. J. Day

On Thu, 12 Aug 2021, Greg KH wrote:

> On Thu, Aug 12, 2021 at 11:45:45AM +0200, Fabio M. De Francesco wrote:
> > Hi Greg,
> >
> > On Monday, August 9, 2021 10:44:23 AM CEST Greg KH wrote:
> > > On Mon, Aug 09, 2021 at 10:15:29AM +0200, Oliver Neukum wrote:
> > > > On 09.08.21 09:58, Muni Sekhar wrote:
> > > > > Hi all,
> > > > >
> > > > > PCIe memory mapped registers can be read via readb(), readw(), readl()
> > > > > kernel API's. Similarly what are the kernel API to read the device
> > > > > registers via USB bus
> > > >
> > > > [...]
> > > >
> > > > I hope this list stays friendly to newcomers and we will answer
> > > > specific questions, but at this point I must advise you to first
> > > > read an introductory book.
> > >
> > > Along these lines, take a look at the book, Linux Device Drivers, third
> > > edition, which is free online, as it has a chapter about USB drivers and
> > > how they work.  That should help you out to understand the issues
> > > involved with USB devices.
> > >
> > I've heard that your book, LDD 3rd edition, has become obsolete a long time
> > ago and most sample code cannot anymore build. Reading what you wrote above
> > seems to contradict what I've been told by others... I must admit that I've
> > just had a print copy of it that I have not yet opened for reading, 
> > therefore
> > maybe that I'm totally wrong in assuming the above.
>
> Look into it and see the differences, it's not hard to notice.
>
> And the code samples are all up to date online on github somewhere,
> there's people keeping them alive if you want to track them down,
> but really, just look at the in-kernel drivers for better examples
> of real drivers.

  it's possibly worth mentioning that a chap named javier martinez has
been doing a decent job of upgrading the examples from LDD3 to keep up
with current kernel development:

  https://github.com/martinezjavier/ldd3

of course, those examples won't match the explanations in the book
anymore, but still, worth perusing.

rday

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

Re: My effort to learn Linux kernel development

2021-07-24 Thread Robert P. J. Day

On Sat, 24 Jul 2021, Constantine Shulyupin wrote:

> On Thu, 22 Jul 2021 at 17:57, Robert P. J. Day  wrote:
> >   as the tech editor of the r. love kernel book, i can safely say that
> > there are no really current kernel books out there anymore -- the best
> > docs are the in-kernel ones.
> >
> >   also, if you want to get started mucking with the kernel and
> > submitting patches, consider improving the documentation -- there is a
> > lot of documentation that is at least a little out of date and could
> > use all the help it can get, and that's an easy and safe way to get
> > started getting your name into the kernel git log.
>
> Here is an attempt to write a new 
> https://en.wikibooks.org/wiki/The_Linux_Kernel
> What do you think?

no. just ... no. if you want to invest your time in writing docs, work
on the in-kernel docs. and i speak as someone who wrote a lot of docs
and kept them at my own web site for years until i realized that was
counter-productive.

rday

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

Re: My effort to learn Linux kernel development

2021-07-23 Thread Robert P. J. Day

On Fri, 23 Jul 2021, Amit Kumar wrote:

... lots of stuff snipped ...

> Thanks for your words. I kindly request your mentorship. So that it
> will be easy for me to make my blog
> (https://freeark1blog.blogspot.com) as a gateway to the Linux kernel
> development.

  i dropped gregkh from this response as i don't think he's interested
in any followup, so here's my thoughts.

  i checked out a couple articles at your blog and i'm not trying to
be harsh, but there's very little useful content there. aside from the
numerous spelling mistakes, the articles are extremely superficial
and, in many cases, are imprecise to the point where it's not clear
what you're even trying to say.

  here's an example:

"Kernel is like the kernel of a nut. It is a bit difficult for an
application program to interact with the kernel directly i.e. it will
be a time consuming task to write an application program with the help
of the kernel only."

  i have no idea what that means, or what point you're trying to get
across, and most of the articles there are like that. if you want to
keep writing, that's great, do whatever you enjoy, but you're being
wildly optimistic if you want to describe your blog as a "gateway to
linux kernel development."

  if i were you, i would do less writing, and way more reading. again,
i'm not trying to discourage you, but you really need to set your
expectations appropriately.

rday

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

Re: My effort to learn Linux kernel development

2021-07-23 Thread Robert P. J. Day

On Fri, 23 Jul 2021, Amit Kumar wrote:

> On Thu, Jul 22, 2021 at 8:26 PM Robert P. J. Day  
> wrote:
> >
> > On Thu, 22 Jul 2021, Jules Irenge wrote:
> >
> > > I normally learn the kernel on weekends. Reading R. Love and
> > > practicing by coding what you learn is the best way. Also, trying to
> > > submit simple patches on some free time is a good way , meeting Greg
> > > Kroah and Shuan, they are fantastic people to learn from.
> Is there any online method to interact with Mr. Greg Kroah Hartman?
> >
> >   as the tech editor of the r. love kernel book, i can safely say that
> > there are no really current kernel books out there anymore -- the best
> > docs are the in-kernel ones.
> I started reading documents from the Documentation folder.
> >
> >   also, if you want to get started mucking with the kernel and
> > submitting patches, consider improving the documentation -- there is a
> > lot of documentation that is at least a little out of date and could
> > use all the help it can get, and that's an easy and safe way to get
> > started getting your name into the kernel git log.
> >
> I know well that there is not any book that provides current knowledge
> about the Linux kernel.
> So, I have decided to make my blog (https://freeark1blog.blogspot.com)
> a gateway to the Linux kernel development.
>
> Why were the last kernel book by Mr. Greg Kroah Hartman and et. al. canceled?

  there's not much financial incentive to write kernel books anymore;
the code base changes so relentlessly that any book is pretty much out
of date by the time it hits the shelves, and few authors want to
invest months of their life for that. and what's the point of having a
small number of authors working on a book, when the entire linux
community is co-operating to improve the inline docs, anyway?

rday

p.s. it also occurs that the kernel is so vast that there's no way
you could do justice to it in a single book. there might (i emphasize
*might*) be some value in writing a comprehensive book on some single
kernel subsystem, but even that would be obviated by decent inline
docs.

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

Re: My effort to learn Linux kernel development

2021-07-22 Thread Robert P. J. Day

On Thu, 22 Jul 2021, Jules Irenge wrote:

> I normally learn the kernel on weekends. Reading R. Love and
> practicing by coding what you learn is the best way. Also, trying to
> submit simple patches on some free time is a good way , meeting Greg
> Kroah and Shuan, they are fantastic people to learn from.

  as the tech editor of the r. love kernel book, i can safely say that
there are no really current kernel books out there anymore -- the best
docs are the in-kernel ones.

  also, if you want to get started mucking with the kernel and
submitting patches, consider improving the documentation -- there is a
lot of documentation that is at least a little out of date and could
use all the help it can get, and that's an easy and safe way to get
started getting your name into the kernel git log.

rday

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

Re: LDD3 vs Essential Linux Device Drivers

2020-05-01 Thread Robert P. J. Day

On Fri, 1 May 2020, Greg KH wrote:

> On Fri, May 01, 2020 at 07:58:11AM +0200, Mohamed Dawod wrote:
> > Hi,
> >
> > I would like to start learning about Linux kernel and device drivers
> > development.
> > Should I have to start with LDD3 as a lot of people advice ? or can I start
> > with the Essential Linux Device Drivers by Sreekrishnan Venkateswaran.
> > I know that the second book may be more advanced but I feel that it's more
> > more practical and easier to be understood.
>
> Why not get both and see which one works for you?

  along with LDD3, there is an ongoing project to update the examples
in that book for newer kernels:

https://github.com/martinezjavier/ldd3

rday

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

Re: Finding bugs/issues to work on

2020-03-24 Thread Robert P. J. Day

On Tue, 24 Mar 2020, Suraj Upadhyay wrote:

> Hii newbies,
>     I just started studying for linux-kernel development although I am not
> completely new to open source technologies. I wanted to clarify my doubts in 
> the
> following things
> 1. Where can I find issues/tickets regarding linux-kernel, to work on ?
> 2. What's the best resource to get started on linux-kernel development ?
> I started reading kernel-newbies guides, though.

  i make this suggestion on a semi-regular basis ... if you want
something that desperately needs doing, work on improving the
documentation. there is never a lack of docs that need improving, and
it gives you a chance to *safely* learn a lot of new stuff.

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

Re: which "make" target simply builds the scripts/dtc/dtc executable?

2020-03-18 Thread Robert P. J. Day

On Sat, 14 Mar 2020, Stefan Wahren wrote:

> Hi,
>
> Am 13.03.20 um 19:13 schrieb rpj...@crashcourse.ca:
> >   colleague has a kernel-compile infrastructure which builds the
> > kernel just fine, but croaks trying to compile .dts files, complaining
> > that there is no "./scripts/dtc/dtc" file.
> >
> >   ok, so that sounds like whatever it is that compiles dtc.c (and
> > friends) into dtc is being omitted. i just want to test whatever
> > make target would normally compile that, but i'm having trouble
> > figuring which make processing does that.
> >
> >   is there a top-level target that wanders into scripts/dtc, and
> > compiles that?
>
> for a ARM target you could try to (PowerPC or MIPS should work too)
>
> export ARCH=arm
> make mxs_defconfig # random arm defconfig
> make dtbs
>
> this should build the devicetree compiler and the devicetree sources,
> but AFAIK newer kernel versions uses the dtc from the Host system. So
> it's possible that the dtc is omitted.

  ah, i had completely missed that newer kernels use the host dtc.

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

Re: New text

2020-02-19 Thread Robert P. J. Day

On Wed, 19 Feb 2020, Ruben Safir wrote:

> is there currently a rfecommended text to learn kernel development
> from?

  not really ... given the speed of development, any book would be out
of date pretty much the instant it hit the shelves. best place to look
is in the in-kernel Documentation.

rday

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

re: how can default Kconfig values be defined elsewhere?

2019-07-30 Thread Robert P. J. Day

On Tue, 30 Jul 2019, kinglotte...@163.com wrote:

> maybe in environment or in 'make' command line I think. 

  quite possibly, but the impression i got from the Documentation file
was that this could be done elsewhere in a different Kconfig file, and
i have no idea how that would be done.

rday

-- 

====
Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

how can default Kconfig values be defined elsewhere?

2019-07-30 Thread Robert P. J. Day



  another kbuild-related question -- from kconfig-language.rst:

  - default value: "default"  ["if" ]

  A config option can have any number of default values. If multiple
  default values are visible, only the first defined one is active.
  Default values are not limited to the menu entry where they are
  defined. This means the default can be defined somewhere else or be
  overridden by an earlier definition.

wait ... default values can be defined elsewhere from the menu entry
for which that default is to be set? i was unaware of this; can
someone provide an example? or am i misreading this?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

first of a few questions about kbuild system

2019-07-30 Thread Robert P. J. Day



  friend who is getting into kernel programming wants to submit a few
patches just to get experience contributing to kernel, and i suggested
there's always potential cleanup in the numerous Kconfig files, but i
want to make *absolutely* sure i'm giving good advice so if i could
clarify a couple things (and, yes, they look trivial, but i've been
burned before thinking things are straightforward).

  first, the doc file kconfig-language.rst proposes the equivalence
between a single "if M" conditional versus individually depending on
the same Kconfig variable in each directive:

  In practice, this is achieved by using one of the next two constructs::

  (1):
  menuconfig M
  if M
  config C1
  config C2
  endif

  (2):
  menuconfig M
  config C1
  depends on M
  config C2
  depends on M

as an example, consider this from the current version of init/Kconfig:

  menuconfig MODULES
bool "Enable loadable module support"
option modules
help

... snip ...

  if MODULES

  ...

  config MODULE_SIG
bool "Module signature verification"
depends on MODULES<---

  ...

  config MODULE_COMPRESS
bool "Compress modules on installation"
depends on MODULES<---

  ... etc etc ...

  endif # MODULES

it *should* be obvious that, between "if MODULES" and the
corresponding "endif", there should be no need for an explicit
dependency on "MODULES", correct? i ask since i have vague memories of
there being some subtleties if Kbuild symbols are tristate rather than
simply bool but, in this case, since MODULES is bool, any such
dependencies should be redundant, correct? am i overlooking any
possible complications?

  as an associated (and much longer) example, in that same
init/Kconfig file:

  menuconfig EXPERT
bool "Configure standard kernel features (expert users)"
# Unhide debug options, to make the on-by-default options visible
select DEBUG_KERNEL
... snip ...

after which there are *numerous* config options whose prompt string is
qualified with conditional "if EXPERT":

  config UID16
bool "Enable 16-bit UID system calls" if EXPERT

all the way down to:

  # end of the "standard kernel features (expert users)" menu

  # syscall, maps, verifier
  config BPF_SYSCALL

assuming that, in the midst of all those config directives, there is
not a single directive that does *not* in some way depend on EXPERT,
could that entire section not simply be wrapped in "if EXPERT" and
"endif" as well?

  i just want to verify that i'm not overlooking, perhaps, any changes
to the Kbuild infrastructure that i'm unaware of. thanks.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: newbie-level question about cgroups

2019-07-29 Thread Robert P. J. Day

On Sun, 28 Jul 2019, Valdis Klētnieks wrote:

> On Sun, 28 Jul 2019 15:39:26 -0400, "Robert P. J. Day" said:
>
> >   no point bugging the actual cgroup people about this since it
> > should be simple ... if i need *only* cgroup v2, can i dispense
> > entirely with everything under /sys/fs/cgroup/ other than
> > /sys/fs/cgroup/unified?
>
> There's a whole mess of CONFIG_CGROUP_* variables, feel free to turn
> off those that your system doesn't actually need.
>
> Make sure that you keep a backup kernel in case you turn off
> something you shouldn't have.  In particular, systemd seems to want
> all sorts of cgroups for no reason other than "because they're
> there".

  actually, i just ran across the "cgroup_no_v1=" boot-time parameter:

[KNL] Disable cgroup controllers and named hierarchies in v1
Format: { { controller | "all" | "named" }
  [,{ controller | "all" | "named" }...] }
Like cgroup_disable, but only applies to cgroup v1;
the blacklisted controllers remain available in cgroup2.
"all" blacklists all controllers and "named" disables
named mounts. Specifying both "all" and "named" disables
    all v1 hierarchies.

so i guess it's not only possible, it's easy. :-)

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

newbie-level question about cgroups

2019-07-28 Thread Robert P. J. Day



  no point bugging the actual cgroup people about this since it should
be simple ... if i need *only* cgroup v2, can i dispense entirely with
everything under /sys/fs/cgroup/ other than /sys/fs/cgroup/unified?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

is there a simple graphic of SATA port multiplier structures?

2019-04-23 Thread Robert P. J. Day



  was just asked to take a look at how SATA II port multipliers are
supported in the linux kernel and, in the midst of all the code and
header files, what seems to be missing is a simple graphic of the main
structures and how many of them there are. let me elucidate.

  imagine, say, a 1-to-4 PMP -- single port multiplexing to four SATA
HDDs. from include/linux/libata.h, i can see the ATA-related
structures that will be involved, but it would be just ducky if there
was a short description as to *how* *many* of each would be involved
in this scenario; that is, a simple counting demonstration would be
massively informative.

  first, it appears that there would be a single ata_port structure:

struct ata_port {
struct Scsi_Host*scsi_host; /* our co-allocated scsi host */
struct ata_port_operations *ops;
spinlock_t  *lock;
/* Flags owned by the EH context. Only EH should touch these once the
   port is active */
unsigned long   flags;  /* ATA_FLAG_xxx */
... snip ...

where one of the possible "flags" settings is:

ATA_FLAG_PMP= (1 << 19), /* controller supports PMP */

so, having only glanced at all of this so far, i assume i would have
one "struct ata_port" with that flag set.

  on the other hand, it would appear i would have four "struct
ata_link"s:

struct ata_link {
struct ata_port *ap;
int pmp;/* port multiplier port # */
... snip ...

finally, what about "struct ata_device":

struct ata_device {
struct ata_link *link;
unsigned intdevno;  /* 0 or 1 */
... snip ...

not having read any further just yet, it's not clear whether there
would be one or four of those, depending on how libata views the
storage devices themselves, but i'm sure i'll figure it out as i keep
reading.

  in the end, it would be terrifically useful if there was a simple
example of how all these structures connected to support a basic
scenario. is that written down anywhere? it doesn't need to be crazy
comprehensive, just the enumeration of the structures involved.

  thoughts?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

would a Kconfig directive "select CONFIG_x" even work?

2019-04-12 Thread Robert P. J. Day



  i could figure this out by RTFM, i suppose, but what the heck ...
given that the proper Kbuild directive would be:

  select x

what would happen if someone accidentally wrote:

  select CONFIG_x

would that fail to select Kbuild directive "x", or would the Kbuild
system quietly strip the "CONFIG_" prefix because it knew what you
really wanted and was trying to be helpful?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: why are some stat.h "S_*" perm macros not exported via uapi?

2019-01-01 Thread Robert P. J. Day

On Mon, 31 Dec 2018, valdis.kletni...@vt.edu wrote:

> On Mon, 31 Dec 2018 14:53:30 -0500, "Robert P. J. Day" said:
>
> >   #define S_IRWXUGO   (S_IRWXU|S_IRWXG|S_IRWXO)
> >   #define S_IALLUGO   (S_ISUID|S_ISGID|S_ISVTX|S_IRWXUGO)
> >   #define S_IRUGO (S_IRUSR|S_IRGRP|S_IROTH)
> >   #define S_IWUGO (S_IWUSR|S_IWGRP|S_IWOTH)
> >   #define S_IXUGO (S_IXUSR|S_IXGRP|S_IXOTH)
>
> Can you give an actual non-contrived example of code where one of
> these would be preferable to inline coding the mask? And do you plan
> to include all the various combos? And why should that be done in
> the uapi headers, rather than glibc/musl/other_c_lib providing it?

... snip ...

  i am not *defending* the above macros, simply pointing out that,
unlike all the other simpler macros that *are* exported via uapi,
these are left all by their lonesome in kernel space. i'm just
wondering if there's a reason for that.

rday

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
  http://crashcourse.ca/dokuwiki

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

why are some stat.h "S_*" perm macros not exported via uapi?

2018-12-31 Thread Robert P. J. Day



  more pedantry ... just noticed this snippet in include/linux/stat.h:

...
  #include 

  #define S_IRWXUGO   (S_IRWXU|S_IRWXG|S_IRWXO)
  #define S_IALLUGO   (S_ISUID|S_ISGID|S_ISVTX|S_IRWXUGO)
  #define S_IRUGO (S_IRUSR|S_IRGRP|S_IROTH)
  #define S_IWUGO (S_IWUSR|S_IWGRP|S_IWOTH)
  #define S_IXUGO (S_IXUSR|S_IXGRP|S_IXOTH)
...

given that all of the other S_ perm macros are exported in
include/uapi/linux/stat.h, as in:

  #define S_IRWXU 00700
  #define S_IRUSR 00400
  #define S_IWUSR 00200
  #define S_IXUSR 00100

  #define S_IRWXG 00070
  #define S_IRGRP 00040
  #define S_IWGRP 00020
  #define S_IXGRP 00010

and so on, is there a reason those few combination perm macros are not
exported as well? or is the userspace stat.h so well-defined at this
point that cosmetic changes like this are frowned upon?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
  http://crashcourse.ca/dokuwiki

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

stylistically, IS_ERR() versus IS_ERR_VALUE()?

2018-12-31 Thread Robert P. J. Day



  poking around error handling in the kernel, and noticed the
following ... in include/linux/err.h, we have IS_ERR() unsurprisingly
defined in terms of IS_ERR_VALUE():

  #define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= \
(unsigned long)-MAX_ERRNO)

  ... snip ...

  static inline bool __must_check IS_ERR(__force const void *ptr)
  {
return IS_ERR_VALUE((unsigned long)ptr);
  }

fair enough, and the above suggests that it's technically equivalent
to use either one, but if i search under drivers/ for each:

  $ git grep -w IS_ERR -- drivers | wc -l
  14048
  $

  $ git grep -w IS_ERR_VALUE -- drivers | wc -l
  48
  $

so IS_ERR() is pretty clearly the call of choice, and the invocations
of IS_ERR_VALUE() are concentrated in a small number of files -- heck,
15 of those calls are in the single file
drivers/net/ethernet/freescale/ucc_geth.c.

  is there any non-obvious reason for driver code to use the latter?
superficially, they *seem* to be equivalent, but i've been surprised
before.

rday

-- 

====
Robert P. J. Day Ottawa, Ontario, CANADA
  http://crashcourse.ca/dokuwiki

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: a specific question...

2018-12-16 Thread Robert P. J. Day

On Sun, 16 Dec 2018, R. Engür Pişirici wrote:

>  Hello All,
>
> Before starting to ask my question, I would like to apologize about
> asking a silly question. Mostly, i always try to find answers by
> reading, searching, digging, etc. However, i really couldnt find a
> proper answer for my question.
>
> My question is about l2tp/pptp drivers in kernel. pptp driver is in
> /drivers/net. But, l2tp driver is in /net I want to know why they
> reside in different paths? What did i miss?

  typically, what you find under /net is code for general networking
*protocols*, while drivers/net contains actual device drivers for
physical devices. sometimes, the split is not perfect.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
  http://crashcourse.ca/dokuwiki

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

how does a PHY driver wildcard on PHY IDs from a .dts file?

2018-12-12 Thread Robert P. J. Day

of the wildcarding used in defining the phy_driver entries must be
available from the PHY ID values in the device tree. and since i don't
have that, i can really define only a single phy_driver entry that
still encompasses all of the possible acme PHY types. is that correct?

  in the end, as i read it, given the scenario i've presented, it
seems that i can define only one level of wildcarding, with one
phy_driver entry that covers all that wildcarding, and all i can do is
wait until i get into the driver init routines to finally read the
PHY's H/W register to determine which of the four PHYs it is.

  i ask this as someone suggested that, no, even in this case, i can
define four phy_driver entries, one to match each *exact* PHY ID, but
i don't see how that's possible given that the exact PHY ID isn't
available until i read the H/W register. so am i misunderstanding
something here?

  anyway, didn't mean to go on this long but i wanted to make sure i
explained this properly. thoughts, anyone?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
  http://crashcourse.ca/dokuwiki

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: suggestions for good in-kernel examples of simple ethernet/PHY drivers?

2018-08-30 Thread Robert P. J. Day

On Thu, 30 Aug 2018, Woody Wu wrote:

> Maybe the dummy NIC driver?
>
> On Thu, Aug 30, 2018 at 7:52 PM  wrote:
>      while i'm actually learning about the intricacies of the kernel 
> networking
>   stack, i was looking for what would be really good examples of existing
>   network drivers that could be used as examples for future tutorials, as
>   nothing is as informational as seeing something that actually works.
>
>      there are, of course, a ton of net drivers already in the kernel, but
>   many of them are fairly complex, and might define custom methods to 
> handle
>   individual quirks and so on, so what i'm interested in is pointers to
>   examples that are nice and simple and straightforward that could be used
>   for a walkthrough of net driver design. thoughts?
>
>   rday
>
>   p.s. i'm already aware of the mass of documentation under
>   Documentation/networking -- any pointers to online net driver
>   design and tutorials would be appreciated.
>
>   and, yes, i'm also digging through LDD3, https://lwn.net/Kernel/LDD3/.

  i'm already looking at that, but what i wanted was an example of an
existing, physical driver that shows how simple the design can be (if
such a thing exists).

rday

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
  http://crashcourse.ca/dokuwiki

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: is there any more to having a single interrupt drive multiple handlers than IRQF_SHARED?

2017-10-26 Thread Robert P. J. Day

On Thu, 26 Oct 2017, valdis.kletni...@vt.edu wrote:

> On Thu, 26 Oct 2017 16:32:42 -0400, "Robert P. J. Day" said:
>
> >   now, i do realize that it can be used along with a unique dev_id
> > values to isolate a *particular* handler amongst a group of
> > handlers, but if one simply wants to trigger *all* handlers
> > registered for that interrupt, is there anything about that that's
> > tricky?
>
> You mean, other than the fact that multiple handlers for the same
> device damned well be coded to know that, and be aware of each
> other?  Locking, etc. and all the other Bad Juju that can happen
> when multiple drivers are all acting on one device.
>
> What problem is your colleague trying to solve by doing this?

  i wish i had more info, but i don't ... all i'm after is that this
is supportable via IRQF_SHARED and, when we chat again tomorrow, i
might be able to figure out whether this is appropriate. having the
handlers play nicely together will be phase two.

rday

p.s. is there an example of this usage somewhere in the kernel i can
point at? i vaguely recall that PCI does something like this, so i'm
off to take a look.

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

wrapping Kconfig "source" directives in "if" statements?

2017-08-25 Thread Robert P. J. Day


  just curious as to Kconfig style, i noticed the following in
drivers/pps/. first, once PPS is selected, the subsequent two config
variables predictably "depend" on PPS:

  menuconfig PPS
tristate "PPS support"
---help---
  ... snip ...

  config PPS_DEBUG
bool "PPS debugging messages"
depends on PPS
help
  ... snip ...

  config NTP_PPS
bool "PPS kernel consumer support"
depends on PPS && !NO_HZ_COMMON
help
  ... snip ...

obviously, those two dependencies on PPS could be removed and those
two config variables could then be wrapped in:

  if PPS
  ...
  endif

but with only two config entries, it's like, meh, no big deal, who
cares?

  but that Kconfig file finishes by sourcing two pps subdirs:

  source drivers/pps/clients/Kconfig
  source drivers/pps/generators/Kconfig

each of which appears to totally depend on PPS; here's the (stripped)
clients/ Kconfig file:

  comment "PPS clients support"
depends on PPS

  config PPS_CLIENT_KTIMER
tristate "Kernel timer client (Testing client, use for debug)"
depends on PPS

  config PPS_CLIENT_LDISC
tristate "PPS line discipline"
depends on PPS && TTY

  config PPS_CLIENT_PARPORT
tristate "Parallel port PPS client"
depends on PPS && PARPORT

  config PPS_CLIENT_GPIO
tristate "PPS client using GPIO"
depends on PPS

same with the pps/generators/Kconfig file. so, rather than all of
those "depends on PPS" lines, would it be equivalent to have the
top-level Kconfig file just look like:

  menuconfig PPS
tristate "PPS support"

  if PPS

  config PPS_DEBUG
bool "PPS debugging messages"

  config NTP_PPS
bool "PPS kernel consumer support"
depends on !NO_HZ_COMMON

  source drivers/pps/clients/Kconfig

  source drivers/pps/generators/Kconfig

  endif

and remove all the lower-level Kconfig "PPS" dependencies? i'm pretty
sure that would be equivalent, would it not? or is there some subtlety
that prevents that?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: what is the current/ongoing state of userspace access to GPIO?

2017-05-25 Thread Robert P. J. Day

On Thu, 25 May 2017, valdis.kletni...@vt.edu wrote:

> On Thu, 25 May 2017 15:20:06 -0400, "Robert P. J. Day" said:
> > On Thu, 25 May 2017, Greg KH wrote:
> >
> > > On Thu, May 25, 2017 at 03:02:24PM -0400, Robert P. J. Day wrote:
> > > >
> > > >   thoughts?
> > >
> > > Why not ask on the linux-gpio mailing list?
> >
> >   huh, i didn't even know there was such a thing.
>
> See http://vger.kernel.org for most of them.  Or look in MAINTAINERS:
>
> GPIO SUBSYSTEM
> M:  Linus Walleij <linus.wall...@linaro.org>
> M:  Alexandre Courbot <gnu...@gmail.com>
> L:  linux-g...@vger.kernel.org
>
> :)

  well, i'm pretty sure i can find it once i know what to look for.
:-)

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: what is the current/ongoing state of userspace access to GPIO?

2017-05-25 Thread Robert P. J. Day

On Thu, 25 May 2017, Greg KH wrote:

> On Thu, May 25, 2017 at 03:02:24PM -0400, Robert P. J. Day wrote:
> >
> >   thoughts?
>
> Why not ask on the linux-gpio mailing list?

  huh, i didn't even know there was such a thing.

rday

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: what is the current/ongoing state of userspace access to GPIO?

2017-05-25 Thread Robert P. J. Day

On Wed, 24 May 2017, Clemens Gruber wrote:

> Hi,
>
> On Wed, May 24, 2017 at 07:58:19AM -0400, Robert P. J. Day wrote:
> >
> >   ashamed to admit, i haven't been keeping up with this, so AIUI,
> > the GPIO sysfs interface is deprecated, replaced with character
> > device files (/dev/gpiochip*) to allow access to GPIO.
> >
> >   first, i find it curious that this is a move away from sysfs
> > access to using ioctl(), since i had always thought ioctls were
> > massively discouraged in new code. is there a document that goes
> > through the rationale for this change?
> >
> >   and i notice under Documentation/ABI/ that sysfs-gpio is listed
> > under "obsolete", while gpio-cdev is listed under "testing". this
> > seems inconsistent -- how can one be obsolete while the other be
> > categorized as testing? that just seems strange.
> >
> >   in any event, is the /dev/gpiochip* interface the recommended
> > interface now? thanks.
>
> Linus Walleij described the rationale in the first commit
> description. Have a look at 3c702e9987e2.
>
> Implementing it with netlink sockets would have made it much more
> complex, I suppose this is why they chose ioctl?
>
> By the way, I can recommend accessing the GPIO chardev with
> libgpiod: https://github.com/brgl/libgpiod
>
> This simplifies using it a lot! The tools are also quite nice.

  thanks, now a couple more (admittedly trivial) questions as i claw
my way through the current state of gpio. the doc file "gpio.txt"
explains that there are two different ways to access GPIO:

  - The descriptor-based interface is the preferred way to manipulate
GPIOs, and is described by all the files in this directory
excepted gpio-legacy.txt.

  - The legacy integer-based interface which is considered deprecated
(but still usable for compatibility reasons) is documented in
gpio-legacy.txt.

the above *seems* to suggest that one can use the newer, preferred
descriptor-based interface and bypass the "legacy" interface, but if i
look in drivers/gpio/Makefile, i see:

  obj-$(CONFIG_GPIOLIB)   += devres.o
  obj-$(CONFIG_GPIOLIB)   += gpiolib.o
  obj-$(CONFIG_GPIOLIB)   += gpiolib-legacy.o  <--- 
  obj-$(CONFIG_GPIOLIB)   += gpiolib-devprop.o

suggesting that if i select GPIOLIB, i get the legacy code compiled,
anyway. is that correct? it seems to disagree with the documentation,
unless that legacy source file is required no matter what, at which
point describing it as "legacy" seems misleading.

  thoughts?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

what is the current/ongoing state of userspace access to GPIO?

2017-05-24 Thread Robert P. J. Day


  ashamed to admit, i haven't been keeping up with this, so AIUI, the
GPIO sysfs interface is deprecated, replaced with character device
files (/dev/gpiochip*) to allow access to GPIO.

  first, i find it curious that this is a move away from sysfs access
to using ioctl(), since i had always thought ioctls were massively
discouraged in new code. is there a document that goes through the
rationale for this change?

  and i notice under Documentation/ABI/ that sysfs-gpio is listed
under "obsolete", while gpio-cdev is listed under "testing". this
seems inconsistent -- how can one be obsolete while the other be
categorized as testing? that just seems strange.

  in any event, is the /dev/gpiochip* interface the recommended
interface now? thanks.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: want to be a kernel developer

2017-02-24 Thread Robert P. J. Day

On Fri, 24 Feb 2017, Kerimcankalipci wrote:

> I strongly recommend Linux Device Drivers book ...

  that book is fairly dated by now, it's not as useful as it once was.

rday

p.s. if you at least want to keep up with updated source for the
sample code, you can find it here:

https://github.com/martinezjavier/ldd3


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

should include/uapi include header files unused in kernel space?

2017-01-22 Thread Robert P. J. Day


  was perusing the UAPI content in the kernel source, prepping for a
course i'm teaching tomorrow, and just noticed there is a header file:

  $ find . -name mtd-user.h
  ./include/uapi/mtd/mtd-user.h
  $

which appears to be *entirely* unreferenced in the entire kernel code
base (outside of the Kbuild file that refers to it):

  $ grep -r 'mtd-user.h' *
  include/uapi/mtd/Kbuild:header-y += mtd-user.h
  $

does this make any sense? am i missing something here? i would have
thought that if a header file includes content that is wholly used
exclusively in user space, it would be part of a package like
"mtd-devel", or something like that.

  is this just for convenience to keep all the mtd stuff in the same
place?

rday

-- 

========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: easiest way to deactivate a driver at boot time?

2016-12-15 Thread Robert P. J. Day

On Thu, 15 Dec 2016, Daniel. wrote:

> Or maybe using [status = "disabled"] at the device tree. Do you
> control the compilation of these device-trees, kernel, drivers and
> apps?

  this sounds like the simplest approach -- u-boot can check things
out and, if necessary, use the FDT utilities to disable the portion of
the tree related to that driver. am i understanding this correctly?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

easiest way to deactivate a driver at boot time?

2016-12-15 Thread Robert P. J. Day


  (Q asked by a colleague, a wee bit vague on details so i'm hoping
i'm describing it correctly, seems like it should be easy to solve.)

  short form of question: what is the standard way of, at boot time,
passing the kernel information to specify that a built-in driver
should *not* be started?

  longer form of question: target system has two "slots", each of
which contains a distinct embedded system running linux. both of those
systems run the same kernel, *except* that, in slot 0, kernel should
start and run a particular driver whereas, in slot 1, the kernel
should *not* start that particular driver, whereupon apps on that
system will fall back and do things differently. (apparently, the apps
will use the simple existence of the driver's /dev/driver special
device file to identify which approach to take.)

  as i understand it, then, whether or not that driver should start is
based simply on being able to identify the slot the board is in, and
this is something that is allegedly available to u-boot, which will
then pass the appropriate info on the kernel command line, telling the
kernel whether or not to start that driver. so far, so good.

  question is, what is the "appropriate" info to pass to the kernel to
identify whether or not to start a (built-in) driver? my initial
reaction was, define a simple module parameter, say "run", which is
tested immediately upon driver startup, and if it's "0", just exit;
otherwise, run normally. and then u-boot would add to the boot line:

  ... drivername.run=0 ...

am i overthinking this? i'm used to module parameters being used to
pass info to drivers and modules to *customize* their behaviour, not
to simply say whether to run or not.

  is this a reasonable way to do this? is there a better/standard way?
and is there a simple example of that in the current kernel source?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

is it accurate to describe /dev/watchdog as "legacy"?

2016-10-15 Thread Robert P. J. Day


  poking around the watchdog code, and in
drivers/watchdog/watchdog_dev.c, i see the snippet:

/*
 *  watchdog_cdev_register: register watchdog character device
 *  @wdd: watchdog device
 *  @devno: character device number
 *
 *  Register a watchdog character device including handling the legacy
^^
 *  /dev/watchdog node. /dev/watchdog is actually a miscdevice and
 *  thus we set it up like that.
 */

  now, my normal understanding of the word "legacy" is of something
that, while it may still function (possibly because of the need for
backward compatibility), it typically refers to something that is,
strictly speaking, *unnecessary*. that is, while one could continue to
interact with the watchdog through the ostensibly "legacy"
/dev/watchdog special file, there is a newer mechanism that makes it
superfluous.

  in this case, i can see the sysfs structure that you can now select
for working with the watchdog; however, in that same file, it
*appears* that almost all of that sysfs structure is for *querying*
watchdog information, not for making changes to it.

  IOW, as i read it (and i could be wrong), while one could extend the
standard watchdog API with sysfs structure, it is still *necessary* to
continue using /dev/watchdog for some things.

  am i reading this correctly? because if i am, then the word "legacy"
should not really apply to /dev/watchdog, should it?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday





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

Re: if/else block default coding style question

2016-10-08 Thread Robert P. J. Day

On Sat, 8 Oct 2016, valdis.kletni...@vt.edu wrote:

> On Sat, 08 Oct 2016 10:40:37 -, Nicholas Mc Guire said:
>
> >} else if (rtlpcipriv->bt_coexist.bt_service == BT_PAN) {
> >rtl_write_byte(rtlpriv, REG_GPIO_MUXCFG, tmp1byte);
> >} else {
> >rtl_write_byte(rtlpriv, REG_GPIO_MUXCFG, tmp1byte);
> >}
>
> That *does* smell like a bug.  If nothing else, the last 'else if'
> can be removed.  Most likely case: somebody cut-n-pasted that last
> section in and failed to change it to a proper 'default' value and
> the code falls through to that one rarely enough that nobody has
> noticed.

  if that's the behaviour the developer actually wants, then yes, it's
messy. but i would be very careful just simplifying it wholesale,
since it also smacks of a typo where one copy-and-pasted to add the
default case, then forgot to tweak it to be different.

  rather than "fixing" it, i would bring it to the attention of the
maintainer, and ask him or her to resolve it.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: Linux Kernel Based Research Projects

2016-10-03 Thread Robert P. J. Day

On Sun, 2 Oct 2016, Daniel Baluta wrote:

> On Sun, Oct 2, 2016 at 2:54 PM, Shyam Saini <mayhs11sa...@gmail.com> wrote:
> > Hi everyone,
> >
> > I'm final year computer science undergraduate student. I want to do my
> > major project based on linux kernel.
> >
> > Would you please suggest me some areas in the kernel which have some
> > projects. To be more specific, I want know on going research areas in
> > kernel. Or some ideas which are not yet implemented.
>
> Would you be interested in taking a look at lguest? [1]
>
> I will be having a presentation about lguest and how one learn
> linux kernel internals by studying lguest code
> this week at LinuxCon Europe [2]
>
> Porting it on x86_64 or any other architecture will be a very cool project
> but I warn you it won't be trivial :).
>
> thanks,
> Daniel.
>
> [1] http://lguest.ozlabs.org/
> [2] http://sched.co/7o92

  Reference [1] claims, "Those crazy guys at Red Hat have an
experimental port of lguest to x86-64: you can grab their git tree."
so why do you say porting to x86_64 wouldn't be trivial?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: Linux Kernel Based Research Projects

2016-10-02 Thread Robert P. J. Day

On Sun, 2 Oct 2016, Shyam Saini wrote:

> Hi everyone,
>
> I'm final year computer science undergraduate student. I want to do
> my major project based on linux kernel.
>
> Would you please suggest me some areas in the kernel which have some
> projects. To be more specific, I want know on going research areas
> in kernel. Or some ideas which are not yet implemented.

  as someone on this list once suggested, saying you want to work on
the linux kernel and want someone to suggest a subsystem is like
saying you want to write a book and could someone suggest a topic for
you to write about.

  if you haven't even progressed to the point where you know what part
of the kernel interests you, you shouldn't be asking for projects.
it's not everyone else's responsibility to do your research for you.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[PATCH] staging: Fix misspelling "dissconect"

2016-08-28 Thread Robert P. J. Day


Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>

---

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 0b1760c..de567bc 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1189,7 +1189,7 @@ static s32 Handle_ConnectTimeout(struct wilc_vif *vif)
result = wilc_send_config_pkt(vif, SET_CFG, , 1,
  wilc_get_vif_idx(vif));
if (result)
-   netdev_err(vif->ndev, "Failed to send dissconect\n");
+   netdev_err(vif->ndev, "Failed to send disconnect\n");

hif_drv->usr_conn_req.ssid_len = 0;
kfree(hif_drv->usr_conn_req.ssid);
@@ -1774,7 +1774,7 @@ static void Handle_Disconnect(struct wilc_vif *vif)
  wilc_get_vif_idx(vif));

if (result) {
-   netdev_err(vif->ndev, "Failed to send dissconect\n");
+   netdev_err(vif->ndev, "Failed to send disconnect\n");
} else {
struct disconnect_info strDisconnectNotifInfo;


-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

[PATCH] staging: ieee80211.h: Correct spelling of "FUNCION"

2016-08-28 Thread Robert P. J. Day


Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>

---

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h 
b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
index 09e9499..e3b4e43 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
@@ -1487,12 +1487,12 @@ typedef enum _RT_PS_MODE
eFastPs // Fast power save mode.
 }RT_PS_MODE;

-typedef enum _IPS_CALLBACK_FUNCION
+typedef enum _IPS_CALLBACK_FUNCTION
 {
IPS_CALLBACK_NONE = 0,
IPS_CALLBACK_MGNT_LINK_REQUEST = 1,
IPS_CALLBACK_JOIN_REQUEST = 2,
-}IPS_CALLBACK_FUNCION;
+}IPS_CALLBACK_FUNCTION;

 typedef enum _RT_JOIN_ACTION{
RT_JOIN_INFRA   = 1,
@@ -1526,7 +1526,7 @@ typedef struct _RT_POWER_SAVE_CONTROL {
struct timer_list   InactivePsTimer;

// Return point for join action
-   IPS_CALLBACK_FUNCIONReturnPoint;
+   IPS_CALLBACK_FUNCTION   ReturnPoint;

// Recored Parameters for rescheduled JoinRequest
boolbTmpBssDesc;

-- 

====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: Pending work related to kernel for a newbie

2016-07-20 Thread Robert P. J. Day

On Wed, 20 Jul 2016, Aleksander Alekseev wrote:

> Hello, Ashijeet
>
> > I am kernel newbie and I was looking for something to work upon to
> > improve my skill-set. I have good knowledge of C and experience in
> > writing patches. Also please refer me if there is a to-do list for
> > newbies related to pending tasks for linux kernel.
>
> I'm newbie here as well. Still I have an experience of working on some
> other open source projects. I believe the idea is always the same.
>
> First, take a look on project's issue tracker:
>
> https://bugzilla.kernel.org/
>
> Also you could probably review an existing code and propose refactoring
> or optimization patches. Static code analyzers is always a good start
> point. Try looking for typos in comments - you will be surprised how
> many mistakes are there. Usually people like to write code but don't
> like to document and/or test it. Join testing and reviewing new
> patches, try to improve them.
>
> I hope this will help.

  i've mentioned this before ... if you want a safe project that will
still teach you a whole lot about the kernel, improve all the
documentation under the Documentation/ directory. there's a *ton* of
stuff there that is either in need of improving or, in some cases,
deletion because it's so old. or if you're feeling really ambitious,
write some *new* documentation for some subsystem for which there is
none.

  and, finally, you can't screw things up by changing the docs.

rday

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: Are these books outdated?

2016-07-14 Thread Robert P. J. Day

On Thu, 14 Jul 2016, Rami Rosen wrote:

> Hi,

> Since there was a concern about these books being outdated, I want
> to mention here also a book titled "Professional Linux Kernel
> Architecture", by Wolfgang Maurer, Wiley, 2008, 1368 pages. (I read
> it partially) And also I agree with Robert saying that he wouldn't
> count on that publication date of LDD4 by Oreilly, since indeed the
> publication date was postponed in the past (at least once but maybe
> more, I am unsure about that)

  first, i wouldn't put any stock in a tentative publication date for
LDD4, as i have already offered to be a technical pre-publication
reviewer for that book, and i have been informed that there is no
guarantee that there will be a new version of that book.

  (frankly, i would doubt it only because there would be *so* *much*
content, it would be hard to pack all that into a single book. i can't
even imagine trying to list everything one would have to cover in that
newer version.)

  however, there are some git repos for the examples in LDD3 that were
being updated to keep up with the kernel source -- here is one of
them:

  https://github.com/martinezjavier/ldd3

i don't know if that code is still maintained, but it's definitely
more relevant than the code snippets from the original LDD3.

  and as far as robert love's "linux kernel development, 3rd ed"
(LKD3) is concerned, i was the technical editor for that book and,
yes, it's also starting to look a bit dated but it's still pretty
decent. once upon a time, i started a wiki page to try to keep up with
changes and additions:

  http://www.crashcourse.ca/wiki/index.php/Updates_to_LKD3

but i just haven't had the time to stay on top of it. perhaps i should
make another concerted effort to get back to that and bring it up to
date again, and add more content (more on this in a bit).

  finally, i once wrote an online course for intro to kernel
programming, it's still here (and, again, being crazy busy has kept me
from updating it but i really want to get back to *that* someday as
well):

http://www.crashcourse.ca/introduction-linux-kernel-programming/introduction-linux-kernel-programming
http://www.crashcourse.ca/introduction-linux-kernel-programming-2nd-edition/introduction-linux-kernel-programming-2nd-edition

the first edition is the more complete of the two, but also the
older; the second edition was meant to be a newer version, but i just
ran out of time moving everything over, but you're welcome to use
whatever you can from either of them -- there's no charge for them, so
help yourself.

  more thoughts on all of this in a bit ...

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: Are these books outdated?

2016-07-14 Thread Robert P. J. Day

On Thu, 14 Jul 2016, François wrote:

> On Thu, Jul 14, 2016 at 02:01:55PM +0300, Aleksander Alekseev wrote:
>
> Hello Aleksander,
>
> I only know LDD 3:
> > * Linux Device Drivers, 3rd Edition (2005)
>
> Since this book is freely available in PDF, I would advise you to
> read it. It is out-dated (in sense you won't compile snippets as is)
> but it is well written, and pleasant to read.
>
> The version 4 was scheduled for dec 2015 iirc, but is now annonced
> for nov 2017 on O'Reilly's website.

  i wouldn't count on that publication date. according to sources,
nothing has been finalized.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: looking for tutorials

2016-06-21 Thread Robert P. J. Day

On Mon, 13 Jun 2016, ty armour wrote:

> I need tutorials on kernel development. And on complete operating
> system development. I would prefer them to be in assembly because it
> is faster, but it seriously needs to get done.
>
> If you are interested, simply post all of the tutorials and other
> relevant information to coding kernels that you can
>
> and show the references, like actually say okay so in order to do
> this we need to look for this in the assembler manual.

  perhaps you'd like a hot oil massage and a nice chablis while you
wait.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

coding style: "obj-y" versus "obj-$(CONFIG_FOO)"?

2016-06-20 Thread Robert P. J. Day


  a bit more pedantry ... in init/Makefile, i see this test:

ifneq ($(CONFIG_BLK_DEV_INITRD),y)
obj-y  += noinitramfs.o
else
obj-$(CONFIG_BLK_DEV_INITRD)   += initramfs.o
endif

which is perfectly correct, but since BLK_DEV_INITRD is defined as a
boolean, it can be assigned only yes or no, so is there any reason
that second assignment wasn't written simply as:

obj-y  += initramfs.o

  sure, it's picky, but whenever i see Makefile content of the form:

obj-$(CONFIG_FOO)

i take into account that that could be a tristate setting. if it
isn't, it just makes more sense aesthetically to me to use "obj-y" for
clarity.

  is there a coding style note about this sort of thing?

rday

-- 

========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

what is the minimal version of make supported for building the kernel?

2016-06-20 Thread Robert P. J. Day


  another curiosity related to my current travels through the
initramfs code, i noticed this git commit from back in 2013:

$ git show 7ac1815683
commit 7ac181568342ec618d4da1ab03c2babcaa7ee84f
Author: Jan Beulich <jbeul...@suse.com>
Date:   Wed Dec 18 17:08:57 2013 -0800

fix build with make 3.80

According to Documentation/Changes, make 3.80 is still being supported
for building the kernel, hence make files must not make (unconditional)
use of features introduced only in newer versions.

Commit 1bf49dd4be0b ("./Makefile: export initial ramdisk compression
config option") however introduced "else ifeq" constructs which make
3.80 doesn't understand.  Replace the logic there with more conventional
(in the kernel build infrastructure) list constructs (except that the
list here is intentionally limited to exactly one element).

Signed-off-by: Jan Beulich <jbeul...@suse.com>
Cc: P J P <ppan...@redhat.com>
Signed-off-by: Andrew Morton <a...@linux-foundation.org>
Signed-off-by: Linus Torvalds <torva...@linux-foundation.org>

diff --git a/Makefile b/Makefile
index 858a147..89cee86 100644
--- a/Makefile
+++ b/Makefile
@@ -732,19 +732,13 @@ export mod_strip_cmd
 # Select initial ramdisk compression format, default is gzip(1).
 # This shall be used by the dracut(8) tool while creating an
initramfs image.
 #
-INITRD_COMPRESS=gzip
-ifeq ($(CONFIG_RD_BZIP2), y)
-INITRD_COMPRESS=bzip2
-else ifeq ($(CONFIG_RD_LZMA), y)
-INITRD_COMPRESS=lzma
-else ifeq ($(CONFIG_RD_XZ), y)
-INITRD_COMPRESS=xz
-else ifeq ($(CONFIG_RD_LZO), y)
-INITRD_COMPRESS=lzo
-else ifeq ($(CONFIG_RD_LZ4), y)
-INITRD_COMPRESS=lz4
-endif
-export INITRD_COMPRESS
+INITRD_COMPRESS-y  := gzip
+INITRD_COMPRESS-$(CONFIG_RD_BZIP2) := bzip2
+INITRD_COMPRESS-$(CONFIG_RD_LZMA)  := lzma
+INITRD_COMPRESS-$(CONFIG_RD_XZ):= xz
+INITRD_COMPRESS-$(CONFIG_RD_LZO)   := lzo
+INITRD_COMPRESS-$(CONFIG_RD_LZ4)   := lz4
+export INITRD_COMPRESS := $(INITRD_COMPRESS-y)

... etc etc ...

  now, Documentation/Changes currently does indeed state:

Current Minimal Requirements

... snip ...
o  GNU make   3.80# make --version

but i did a quick grep to find:

  $ grep -r "else ifeq" *
  lib/raid6/test/Makefile:else ifeq ($(HAS_NEON),yes)
  $

so would that single test not violate the rule just described above?
is Documentation/Changes entirely up to date with respect to minimal
requirements?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

confused about use of "INITRD_COMPRESS" lines in top-level Makefile

2016-06-20 Thread Robert P. J. Day


  currently poring over the initramfs code, and i'm a bit curious
about the following.

  in usr/Kconfig, all the possible compression protocols can be
selected, and by default are:

config RD_GZIP
bool "Support initial ramdisks compressed using gzip"
default y
select DECOMPRESS_GZIP
help
  Support loading of a gzip-encoded initial ramdisk or cpio buffer.
  If unsure, say Y.

config RD_BZIP2
bool "Support initial ramdisks compressed using bzip2"
default y
select DECOMPRESS_BZIP2
help
  Support loading of a bzip2-encoded initial ramdisk or cpio buffer.
  If unsure, say N.

... etc etc ...

but in the top-level Makefile, here are the lines that ostensibly
select which compression to actually use:

  # Select initial ramdisk compression format, default is gzip(1).
  # This shall be used by the dracut(8) tool while creating an initramfs image.
  #
  INITRD_COMPRESS-y  := gzip
  INITRD_COMPRESS-$(CONFIG_RD_BZIP2) := bzip2
  INITRD_COMPRESS-$(CONFIG_RD_LZMA)  := lzma
  INITRD_COMPRESS-$(CONFIG_RD_XZ):= xz
  INITRD_COMPRESS-$(CONFIG_RD_LZO)   := lzo
  INITRD_COMPRESS-$(CONFIG_RD_LZ4)   := lz4
  # do not export INITRD_COMPRESS, since we didn't actually
  # choose a sane default compression above.
  # export INITRD_COMPRESS := $(INITRD_COMPRESS-y)

so as i read this, the single compression protocol selected will be
the last one configured in that list, but where is that variable
eventually used? where is the build code or utility that examines the
value eventually set and invokes dracut, as the comment suggests?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

[PATCH] Small number of aesthetic/dependency cleanups in usr/Kconfig

2016-06-20 Thread Robert P. J. Day


* Remove superfluous dependencies on BLK_DEV_INITRD.
* Couple grammar fixes.
* Add proper hyphenation.
* Add periods at end of some help sentences.

Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>

---

  only place i'm not absolutely confident is the removal of those
dependency lines but, AFAICT, this Kconfig file is sourced only from
init/Kconfig, which contains:

  if BLK_DEV_INITRD

  source "usr/Kconfig"

  endif

so unless that Kconfig file is sourced from elsewhere, this should be
fine.


diff --git a/usr/Kconfig b/usr/Kconfig
index 572dcf7..392021d 100644
--- a/usr/Kconfig
+++ b/usr/Kconfig
@@ -26,7 +26,7 @@ config INITRAMFS_ROOT_UID
depends on INITRAMFS_SOURCE!=""
default "0"
help
- This setting is only meaningful if the INITRAMFS_SOURCE is
+ This setting is only meaningful if the INITRAMFS_SOURCE
  contains a directory.  Setting this user ID (UID) to something
  other than "0" will cause all files owned by that UID to be
  owned by user root in the initial ramdisk image.
@@ -38,7 +38,7 @@ config INITRAMFS_ROOT_GID
depends on INITRAMFS_SOURCE!=""
default "0"
help
- This setting is only meaningful if the INITRAMFS_SOURCE is
+ This setting is only meaningful if the INITRAMFS_SOURCE
  contains a directory.  Setting this group ID (GID) to something
  other than "0" will cause all files owned by that GID to be
  owned by group root in the initial ramdisk image.
@@ -47,54 +47,48 @@ config INITRAMFS_ROOT_GID

 config RD_GZIP
bool "Support initial ramdisks compressed using gzip"
-   depends on BLK_DEV_INITRD
default y
select DECOMPRESS_GZIP
help
- Support loading of a gzip encoded initial ramdisk or cpio buffer.
+ Support loading of a gzip-encoded initial ramdisk or cpio buffer.
  If unsure, say Y.

 config RD_BZIP2
bool "Support initial ramdisks compressed using bzip2"
default y
-   depends on BLK_DEV_INITRD
select DECOMPRESS_BZIP2
help
- Support loading of a bzip2 encoded initial ramdisk or cpio buffer
+ Support loading of a bzip2-encoded initial ramdisk or cpio buffer.
  If unsure, say N.

 config RD_LZMA
bool "Support initial ramdisks compressed using LZMA"
default y
-   depends on BLK_DEV_INITRD
select DECOMPRESS_LZMA
help
- Support loading of a LZMA encoded initial ramdisk or cpio buffer
+ Support loading of a LZMA-encoded initial ramdisk or cpio buffer.
  If unsure, say N.

 config RD_XZ
bool "Support initial ramdisks compressed using XZ"
-   depends on BLK_DEV_INITRD
default y
select DECOMPRESS_XZ
help
- Support loading of a XZ encoded initial ramdisk or cpio buffer.
+ Support loading of a XZ-encoded initial ramdisk or cpio buffer.
  If unsure, say N.

 config RD_LZO
bool "Support initial ramdisks compressed using LZO"
default y
-   depends on BLK_DEV_INITRD
select DECOMPRESS_LZO
help
- Support loading of a LZO encoded initial ramdisk or cpio buffer
+ Support loading of a LZO-encoded initial ramdisk or cpio buffer.
  If unsure, say N.

 config RD_LZ4
bool "Support initial ramdisks compressed using LZ4"
default y
-   depends on BLK_DEV_INITRD
select DECOMPRESS_LZ4
help
- Support loading of a LZ4 encoded initial ramdisk or cpio buffer
+ Support loading of a LZ4-encoded initial ramdisk or cpio buffer.
  If unsure, say N.

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: Use of list_head struct

2016-06-20 Thread Robert P. J. Day

On Mon, 20 Jun 2016, Bogdan PRICOP wrote:

> Bogdan PRICOP
> 
> Mobile: +353 86 075 3349
> E-mail: pric...@gmail.com
> 
>
> On 17 June 2016 at 11:35, Pranay Srivastava <pran...@gmail.com> wrote:
> >
> > On Fri, Jun 17, 2016 at 3:41 PM, Martin Houry <martinho...@gmail.com> wrote:
> > > Hello mailing list!
> > > I've read some code in the NFS4.1 client. I have trouble to access
> > > variables in a list_head.
> > >
> > > So I have :
> > > (include/linux/sunrpc/xprt.h line 168)
> > > struct rpc_xprt{
> > > .
> > > .
> > >
> > > struct rpc_wait_queue pending; /* requests in flight */
> > > .
> > > .
> > > }
> > >
> > > ==>
> > >
> > > struct rpc_wait_queue {
> > > .
> > > struct list_headtasks[RPC_NR_PRIORITY]; /* task queue for
> > > each priority level */
> > > .
> > > }
> > >
> > > The struct "list_head" is a classical  linked list. But How do I know
> > > the type of the struct in this list?
> > > I can maybe guess the struct in it :
> > >
> > > struct rpc_task {}
> > >
> > > But how can I be certain that "struct list_head tasks" contains some
> > > "struct rpc_task"?
> >
> > some magic value perhaps?
> >
> > >
> > > I'm new here, thank you for your help!
> > > Martin
> > >
>
> Hi Martin,
>
> I think the main idea behind Linux kernel implementation of the linked
> list (struct list_head) is to work with any kind of items which need
> to be linked.
>
> Please have a look at the below links which explain the internals of
> Linux kernel list and its usage:
> https://isis.poly.edu/kulesh/stuff/src/klist/
> http://www.makelinux.net/ldd3/chp-11-sect-5

  i wrote a page on that way back here:

http://crashcourse.ca/introduction-linux-kernel-programming/intermission-lets-talk-about-linked-lists-and-containerof-free

as part of a kernel programming course that i *really* need to get
back to someday and update. *sigh*.

rday


-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

want to clarify a couple things about initramfs

2016-06-19 Thread Robert P. J. Day


  for the first time, i'm going to dive into the kernel support for
initramfs, so i'll start with a couple questions.

  first, i note that the Doc file ramfs-rootfs-initramfs.txt seems(?)
a bit dated, in that it refers to the 2.6 kernel, but it may just mean
that it's relevant for 2.6 and everything newer, so it may be just
fine, i guess i'll find out eventually.

  next (and possibly a silly question), i know that the primary(?)
purpose of an initramfs is to load an early rootfs to get access to
kernel modules, after which one tosses away the initramfs and mounts
the "real" rootfs. but i'm pretty sure i have the right to build a
kernel with enough of an initramfs that i can run off that embedded
initramfs entirely out of RAM if all i want to do is, say, basic
diagnostics.

  next, from the Doc file, i see the possibility of a second
(external) initramfs:


External initramfs images:
--

If the kernel has initrd support enabled, an external cpio.gz archive can also
be passed into a 2.6 kernel in place of an initrd.  In this case, the kernel
will autodetect the type (initramfs, not initrd) and extract the external cpio
archive into rootfs before trying to run /init.

This has the memory efficiency advantages of initramfs (no ramdisk block
device) but the separate packaging of initrd (which is nice if you have
non-GPL code you'd like to run from initramfs, without conflating it with
the GPL licensed Linux kernel binary).

It can also be used to supplement the kernel's built-in initramfs image.  The
files in the external archive will overwrite any conflicting files in
the built-in initramfs archive.  Some distributors also prefer to customize
a single kernel image with task-specific initramfs images, without
recompiling."


  is all that still accurate? again, i'm sure i can confirm that once
i start digging through the code. in my case, i don't think i'll need
an external initramfs if i can cram everything i need into the one
embedded in the kernel.

  thoughts?

rday

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: list etiquette

2016-06-06 Thread Robert P. J. Day

On Mon, 6 Jun 2016, Tobin Harding wrote:

> LKML list etiquette question.
>
> When asking a [simple] question that receives an suitable answer is
> it correct etiquette to reply with a thank you email or is this just
> adding noise to the list?

  i would just let it go, unless you have something you want to add,
or possibly a summary that would be useful for future readers.

rday

p.s. conversely, if you're *answering* someone's question, take the
time to really flesh it out so it's as useful as possible to as many
people as possible.

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: why is there still so much KERNEL testing in include/uapi/?

2016-05-27 Thread Robert P. J. Day

On Fri, 27 May 2016, Greg KH wrote:

> On Fri, May 27, 2016 at 12:08:09PM -0400, Robert P. J. Day wrote:
> >
> >   continuing down this road of exporting kernel headers, under
> > include/uapi/ (and mostly further under linux/), there's still a *ton*
> > of testing of the __KERNEL__ preprocessor check.
> >
> >   now, i realize that when one does "make headers_install", all those
> > files are run through "unifdef" to sanitize almost all of that kernel
> > content, so it's not like it hurts, but is there any reason so much of
> > it is still there? wouldn't it be tidier to get rid of it?
>
> No, because not all of the information in those .h files should be
> exported to userspace.  You could either split the files all up into
> two different ones, or just live with the existing infrastructure we
> have. We chose the easy one :)

  ok, i think i see *part* of my misunderstanding so let me back up a
bit ... are any of the header files *directly* under include/linux
processed for exporting? because there is no file
include/linux/Kbuild, which i assume needs to exist for that to
happen.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday




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

Re: exporting kernel headers via the include/uapi directory

2016-05-27 Thread Robert P. J. Day

On Fri, 27 May 2016, Greg KH wrote:

> On Fri, May 27, 2016 at 08:07:17AM -0400, Robert P. J. Day wrote:
> >
> >   next question about exporting kernel headers, this one related to
> > the content placed under include/uapi/.
> >
> >   is there any rationale for header files to be living under
> > include/uapi/ if they're not listed in the corresponding
> > Kbuild file for export?
> >
> >   for example, in include/uapi/drm, there are 24 header files, but
> > only 21 of them are mentioned in that Kbuild file -- the Kbuild file
> > doesn't mention armada_drm.h, etnaviv_drm.h or omap_drm.h, and i've
> > verified that running "make headers_install" doesn't install those
> > three headers.
> >
> >   i'm going to assume those are just forgotten remnants or something,
> > unless there is some actual reason to do that. is there?
>
> Why not ask this on the drm mailing list?

  because drm is not the only subdirectory for which that's true, and
the question really is a generic one.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

why is there still so much KERNEL testing in include/uapi/?

2016-05-27 Thread Robert P. J. Day


  continuing down this road of exporting kernel headers, under
include/uapi/ (and mostly further under linux/), there's still a *ton*
of testing of the __KERNEL__ preprocessor check.

  now, i realize that when one does "make headers_install", all those
files are run through "unifdef" to sanitize almost all of that kernel
content, so it's not like it hurts, but is there any reason so much of
it is still there? wouldn't it be tidier to get rid of it?

  or is there some rationale for leaving it there?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: exporting kernel headers via the include/uapi directory

2016-05-27 Thread Robert P. J. Day

On Fri, 27 May 2016, Bjørn Mork wrote:

> "Robert P. J. Day" <rpj...@crashcourse.ca> writes:
>
> >   while i'm here, some pedantry ... what is the point of adding a
> > header file somewhere under include/uapi/ without
> > *immediately* adding it to the Kbuild file so that it's exported?
>
> I don't know the answer to that.  But having done this once, I can
> answer why *I* did it: Ignorance.
>
> I didn't realize that I had to update the Kbuild file, but wrongly
> assumed that creating a file somewhere in include/uapi was enough.
> Maybe that's the reason for most of these errors?  Some automatic
> check, or maybe even automatic fix, would be nice.  Should be pretty
> easy to do.

  unless there really is some reason to not do those two things at
the same time, but for the life of me, i can't imagine what it is.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: exporting kernel headers via the include/uapi directory

2016-05-27 Thread Robert P. J. Day

On Fri, 27 May 2016, Robert P. J. Day wrote:

>   next question about exporting kernel headers, this one related to
> the content placed under include/uapi/.
>
>   is there any rationale for header files to be living under
> include/uapi/ if they're not listed in the corresponding
> Kbuild file for export?
>
>   for example, in include/uapi/drm, there are 24 header files, but
> only 21 of them are mentioned in that Kbuild file -- the Kbuild file
> doesn't mention armada_drm.h, etnaviv_drm.h or omap_drm.h, and i've
> verified that running "make headers_install" doesn't install those
> three headers.
>
>   i'm going to assume those are just forgotten remnants or
> something, unless there is some actual reason to do that. is there?

  while i'm here, some pedantry ... what is the point of adding a
header file somewhere under include/uapi/ without
*immediately* adding it to the Kbuild file so that it's exported?

  for example, i note that include/uapi/drm/amdgpu_drm.h was committed
back in april of 2015, but a "headers-y" line for it wasn't added
until nov of that same year. so what was that header file doing all
that time in between?

  or is there some mechanism that allows export of UAPI header files
even if they're not mentioned in Kbuild?

rday

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

exporting kernel headers via the include/uapi directory

2016-05-27 Thread Robert P. J. Day


  next question about exporting kernel headers, this one related to
the content placed under include/uapi/.

  is there any rationale for header files to be living under
include/uapi/ if they're not listed in the corresponding
Kbuild file for export?

  for example, in include/uapi/drm, there are 24 header files, but
only 21 of them are mentioned in that Kbuild file -- the Kbuild file
doesn't mention armada_drm.h, etnaviv_drm.h or omap_drm.h, and i've
verified that running "make headers_install" doesn't install those
three headers.

  i'm going to assume those are just forgotten remnants or something,
unless there is some actual reason to do that. is there?

rday

-- 

========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

some simple(?) questions about Kbuild and installing kernel headers

2016-05-27 Thread Robert P. J. Day


  for various reasons, i'm poring over the grotty details of the
installation of kernel headers, so a couple questions before i get any
further into the code.

  first, is there any value to a Kbuild file with no content? for
example, here's the entirety of
arch/cris/include/arch-v10/arch/Kbuild:

# CRISv10 arch

that is, one commented-out line, no references to any include files.
does such a file have any meaning? or can such files be deleted until
such time as they need to contain some content?

  next, with an example from that same directory, the "page.h" header
file:

#ifndef _CRIS_ARCH_PAGE_H
#define _CRIS_ARCH_PAGE_H

#ifdef __KERNEL__

... snip ...

#endif
#endif

  in other words, the *entirety* of the contents of that header file
are protected by "__KERNEL__". first, that seems silly given that we
know the Kbuild file is empty (but that's admittedly an obscure
situation).

  but even if the Kbuild file *wasn't* empty, there are two sub-cases.
first, if the "page.h" header file isn't being exported to user space,
there's no need for any use of __KERNEL__ to begin with since it's
exclusively a kernel header file.

  and if it *is* being exported, what ends up being exported is, well,
an empty header file, correct? which seems a bit silly, *unless* ...
are there cases where certain header files *must* exist in user space
just as placeholders, even if they're empty? that would explain it,
but it still seems yucky.

  one last query ... is there any value to an unexported header file
containing any __KERNEL__ protection? i'm assuming not; examples of
that are probably just leftovers that weren't cleaned up properly.

  more questions later as i get deeper into the code ...

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

is there any actual usage of the device tree node "/chosen@0"?

2016-05-23 Thread Robert P. J. Day


  currently perusing the kernel code for device tree processing and
stumbled across this in drivers/of/base.c:

  void of_alias_scan(void * (*dt_alloc)(u64 size, u64 align))
  {
struct property *pp;

of_aliases = of_find_node_by_path("/aliases");
of_chosen = of_find_node_by_path("/chosen");
if (of_chosen == NULL)
of_chosen = of_find_node_by_path("/chosen@0");  ?

if (of_chosen) {
... snip ...

that pretty clearly says that "/chosen@0" is an equivalent node name
for "/chosen", correct? but why was that equivalence first defined?

  if i scan the entire kernel source tree, this is all i get:

$ grep -r "/chosen@0" *
arch/powerpc/boot/oflib.c:  chosen = of_finddevice("/chosen@0");
drivers/of/base.c:  of_chosen = of_find_node_by_path("/chosen@0");
drivers/of/fdt.c:   offset = fdt_path_offset(fdt, "/chosen@0");
$

so there are apparently three files that *check* for that alternate
name, but not a single .dts or .dtsi that actually uses it. is there
any value to that alternate name?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

what is the point of "dt-bindings" symlinks under some arches?

2016-05-22 Thread Robert P. J. Day


  i'm curious about the value of the small number of "dt-bindings"
symlinks under some architectures that all simply link to the
top-level include/dt-bindings/ directory:

$ find . -name dt-bindings -exec ls -ld {} \;
lrwxrwxrwx. 1 rpjday rpjday 34 Apr 26 13:07 
./arch/cris/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings
lrwxrwxrwx. 1 rpjday rpjday 34 Apr 25 10:58 
./arch/powerpc/boot/dts/include/dt-bindings -> 
../../../../../include/dt-bindings
lrwxrwxrwx. 1 rpjday rpjday 34 Apr 25 10:57 
./arch/metag/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings
lrwxrwxrwx. 1 rpjday rpjday 34 Apr 25 10:57 
./arch/arm64/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings
lrwxrwxrwx. 1 rpjday rpjday 34 Apr 25 10:57 
./arch/arm/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings
lrwxrwxrwx. 1 rpjday rpjday 34 Apr 25 10:57 
./arch/mips/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings
drwxrwxr-x. 26 rpjday rpjday 4096 Apr 26 13:07 ./include/dt-bindings
$

  normally, i expect to see setups like that in cases where,
historically, an architecture kept track of its own content and, at
some point, it was centralized, so the previous directory (whatever it
contained) was simply replaced by a symlink.

  but even without that arch-specific symlink, wouldn't the top-level
include/dt-bindings/ directory be searched, anyway? or maybe not, i
guess i'll check the Makefile to see if it would be.

  thoughts? given that all those symlinks are absolutely identical,
couldn't they all just be removed?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: LINKS PLEASE

2016-05-17 Thread Robert P. J. Day

On Tue, 17 May 2016, Gnoleba GNOGBO wrote:

> Hi !
> I am beginning my learn of Linux !
> Can you show (give) me the good link for :
>
>  1. the management of the all memory in Linux ( Rom, Ram, cache, Registers, 
> swap and fs)
>  2. the management of the all process (initialization, user process, kernel 
> process )
>  3. the all tables in memory to manage the data and process
>
> Regards
>
> Gnoleba

  there is no way this is serious.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: How to contact to Greg.

2016-05-13 Thread Robert P. J. Day

On Fri, 13 May 2016, Sudip Mukherjee wrote:

> On Fri, May 13, 2016 at 04:59:32PM +0800, Aric wrote:
> > Hi Valdis,
> >   Do you mean the Grag is "Greg KH"<g...@kroah.com>; ?  But I'm still 
> > learning, where can I get a simple task to get into? The test task is also 
> > okay, pls give me test specification or what test env. it required.
>
> There is no Grag, we only have Greg KH.

  "I am Grag."

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: How to fast master kernel

2016-05-10 Thread Robert P. J. Day

On Tue, 10 May 2016, valdis.kletni...@vt.edu wrote:

> On Tue, 10 May 2016 16:58:26 -0400, "Robert P. J. Day" said:
>
> >   not sure who it was (maybe even valdis) who once said, "Saying you
> > want to get into kernel programming but have no idea where to start so
> > can someone give you suggestions is like saying you want to write a
> > book but don't know what to write about so can someone give you any
> > ideas."
>
> Yeah, that was me...
>
> I'm also the one who said that we're approaching the point where the
> number of people who are actually qualified to do serious hacking on
> the kernel innards (like the scheduler, vfs, etc, not just a driver)
> is on the same order of magnitude as the number of people qualified
> to be Formula-1 race car mechanics

  all those F-1 race cars run linux, anyway, so ... no big deal.

rday

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: How to fast master kernel

2016-05-10 Thread Robert P. J. Day

On Tue, 10 May 2016, valdis.kletni...@vt.edu wrote:

> On Tue, 10 May 2016 10:58:43 +0800, "Aric" said:
>
> > I'm a newcomer, hope to learn linux kernel together. How can I
> > contribute to kernel programming? Any good tutorials and tranings
> > ? Why so silence this mail-alias.
>
> Step 0: Figure out *why* you want to contribute.  The answer you
> seek depends a lot on why you're asking the question

... snip ...

  not sure who it was (maybe even valdis) who once said, "Saying you
want to get into kernel programming but have no idea where to start so
can someone give you suggestions is like saying you want to write a
book but don't know what to write about so can someone give you any
ideas."

rday

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: what is the rationale for all ethernet device vendors being "default y"?

2016-05-04 Thread Robert P. J. Day

On Wed, 4 May 2016, Bjørn Mork wrote:

> "Robert P. J. Day" <rpj...@crashcourse.ca> writes:
>
> >   just noticed that on my x86 system, when i do a:
> >
> >   $ make defconfig
> >
> > under "Ethernet driver support", all the top-level vendor choices
> > (3com, adaptec and so on) all have Kconfig entries with:
> >
> >   default y
> >
> > reasonably, for each vendor, all of their cards are not "default y"
> > (that would be kind of silly), but what is the logic behind making
> > each vendor selection "default y"?
>
> To avoid introducing build regressions with the introduction of these
> directories:
> http://lists.openwall.net/netdev/2011/08/23/41
>
> This is because these directories were retro-fitted to the Kbuild system
> for most ethernet drivers.

  ah, makes perfect sense, thanks.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

what is the rationale for all ethernet device vendors being "default y"?

2016-05-04 Thread Robert P. J. Day


  just noticed that on my x86 system, when i do a:

  $ make defconfig

under "Ethernet driver support", all the top-level vendor choices
(3com, adaptec and so on) all have Kconfig entries with:

  default y

reasonably, for each vendor, all of their cards are not "default y"
(that would be kind of silly), but what is the logic behind making
each vendor selection "default y"?

  i ask because i'm putting together some kernel configuration
fragments that will contribute to a final .config file and, because of
all that "default y" stuff, i explicitly have to add "is not set"
lines to my fragments to turn off all the vendors in which i have no
interest.

  admittedly, as i read it, leaving them as "default y" doesn't seem
to generate any additional code unless you actually select a board
from that vendor; still, is there a reason the Kconfig files are set
up the way they are?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday





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

Re: anyone aware of a high availability setup that relies on fully redundant install?

2016-04-18 Thread Robert P. J. Day

On Mon, 18 Apr 2016, valdis.kletni...@vt.edu wrote:

> On Sun, 17 Apr 2016 10:47:55 -0400, "Robert P. J. Day" said:
> >   i figure this is as good a place as any to ask ... is anyone here
> > aware of anyone using a linux config and install that, for the
> > purposes of reliability or high availability or whatever you want to
> > call it, relies on a second, completely independent installation of
> > linux on the same hard drive?
>
> IBM's AIX has for a long time had the concept of an 'alternate boot
> volume', which can be another logical volume on the same physical
> hard drive.  But it's not intended for high-availability, it's for
> "if this software upgrade goes pear-shaped I have an easy backout
> procedure".  And it avoids most of the "you have to keep two
> version" issues by providing a tool to copy your *current* system
> onto the alternate boot.  I'm sure some Linux distros have stolen
> the concept.

  that makes sense -- a *minimal* bootable system for recovery and
troubleshooting. but not a fully independent previous install.

> Most implementations of "high availability" would see the phrase "on
> the same hard drive" and start pointing and laughing at the single
> point of failure.

  trust me, i'm aware of that. :-) perhaps i shouldn't have used the
phrase "high availability", this proposal was more for just the
ability to back out of a botched or flawed upgrade.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

of device trees and powerpcs and low memory

2016-04-18 Thread Robert P. J. Day


  a question about device trees for those (probably numerous) members
of this list that know more about them than i do.

  recently, was given the following patch to be applied to a device
tree source file for a fairly elderly (MPC83xx-based) powerpc platform
that has 1G of RAM:

memory {
device_type = "memory";
linux,phandle = <300>;
-   reg = <0x 0x4000>;
+   reg = <0x 0x2000>;
};


i was puzzled by the change that now seemed to define 512M of RAM
instead of the full 1G. the explanation i was given is that that is
how one defines where kernel low memory ends, thereby leaving the
remaining 512M for high memory in kernel space.

  that's the first i ever heard of that. is it true? and if it is,
where in the kernel source code can i see that information being
processed and low memory being established based on reading that node
from the DTB?

  in any event, i'd never heard this before -- if i was going to
define low memory on a powerpc, i would think the proper way is to use
this snippet from arch/powerpc/Kconfig:

  menu "Advanced setup"
depends on PPC32

  config ADVANCED_OPTIONS
bool "Prompt for advanced kernel configuration options"
help
  This option will enable prompting for a variety of advanced kernel
  configuration options.  These options can cause the kernel to not
  work if they are set incorrectly, but can be used to optimize certain
  aspects of kernel memory management.

  Unless you know what you are doing, say N here.

  comment "Default settings for advanced configuration options are used"
depends on !ADVANCED_OPTIONS

  config LOWMEM_SIZE_BOOL
bool "Set maximum low memory"
depends on ADVANCED_OPTIONS
help
  This option allows you to set the maximum amount of memory which
  will be used as "low memory", that is, memory which the kernel can
  access directly, without having to set up a kernel virtual mapping.
  This can be useful in optimizing the layout of kernel virtual
  memory.

  Say N here unless you know what you are doing.

  config LOWMEM_SIZE
hex "Maximum low memory size (in bytes)" if LOWMEM_SIZE_BOOL
default "0x3000"


thoughts? i thought i understood device trees reasonably well, but i
had never heard of this alleged configuration.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: anyone aware of a high availability setup that relies on fully redundant install?

2016-04-17 Thread Robert P. J. Day

On Sun, 17 Apr 2016, Greg KH wrote:

> On Sun, Apr 17, 2016 at 10:47:55AM -0400, Robert P. J. Day wrote:
> >
> >   i figure this is as good a place as any to ask ... is anyone here
> > aware of anyone using a linux config and install that, for the
> > purposes of reliability or high availability or whatever you want to
> > call it, relies on a second, completely independent installation of
> > linux on the same hard drive?
>
> ChromeOS and CoreOS do this.  There's lots of documentation on the
> ChromeOS site for how this works and what is involved.

  interesting ... does the CoreOS functionality depend on containers?
what little i know about CoreOS, i would think there's no way to use
it *without* containers.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

anyone aware of a high availability setup that relies on fully redundant install?

2016-04-17 Thread Robert P. J. Day


  i figure this is as good a place as any to ask ... is anyone here
aware of anyone using a linux config and install that, for the
purposes of reliability or high availability or whatever you want to
call it, relies on a second, completely independent installation of
linux on the same hard drive?

  i was having a discussion about the reliability of upgrading linux
(any combination of kernel, basic rootfs and/or proprietary apps), and
one approach that was suggested (not by me) was to have two entirely
independent installations on the same hard drive so that, when one
"upgraded" the system, the newer content was installed in the other
partition and the system rebooted to that newer content, the rationale
being that, if the upgraded system didn't work, one could revert back
to the original install.

  the history of this particular approach lies in the fact that the
original S/W running on the system in question was an embedded app
programmed right on bare metal, so the entire app was basically a
monolithic combination of boot loader, kernel and all the apps. in
that case, i can certainly see how one wanted a reliable way to revert
back to a known working system if the new S/W had flaws. but i don't
think that logic holds with a linux installation.

  the major concern seems to be a fear that, if one upgrades the
kernel even a little bit, user space apps might suddenly stop working
because of some new incompatibility introduced by that upgrade. i'm
well aware of gregkh's piece on kernel stable API nonsense:

https://www.kernel.org/doc/Documentation/stable_api_nonsense.txt

so i'm not overly worried, but folks in the discussion coming from the
embedded programming space are using their experiences from that space
to argue that a fully redundant install is the safest approach just in
case something goes wrong with an upgrade.

  not surprisingly, my position is that this is not something they
need to worry about a whole lot but, for the sake of fairness, i
thought i'd look around to see if any linux folks *are* using that
approach.

  anyone? thoughts?

rday

-- 

========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday




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

what is the purpose of "LOCALVERSION" variable in scripts/setlocalversion?

2016-04-09 Thread Robert P. J. Day


  i was perusing "scripts/setlocalversion" to see the variations for
setting the kernel version, and i ran across this snippet:

  # CONFIG_LOCALVERSION and LOCALVERSION (if set)
  res="${res}${CONFIG_LOCALVERSION}${LOCALVERSION}"

i'm well aware of the kernel *config* option CONFIG_LOCALVERSION, but
i was unaware of the apparently independent variable "LOCALVERSION"
which is used in that assignment.

  there's precious little mention of that variable ... under what
circumstances does one set it? is it meant to be set in the user's
environment and simply inherited that way? is anyone here using it on
a regular basis?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: variant length array?

2016-04-05 Thread Robert P. J. Day

On Tue, 5 Apr 2016, Bjørn Mork wrote:

> "Robert P. J. Day" <rpj...@crashcourse.ca> writes:
> > On Tue, 5 Apr 2016, Wenda Ni wrote:
> >
> >> Hi all,
> >>
> >> I come across the following code in a kernel module code. It defines
> >> an array whose length is variant at runtime, depending on the actual
> >> inputs. It seems that kernel compiler supports this, which is
> >> obvious an error in the standard ANSI C. Do I have the correct
> >> understanding on it?
> >>
> >> Thank you.
> >>
> >>
> >> u32 rxe_icrc_hdr(struct rxe_pkt_info *pkt, struct sk_buff *skb)
> >> {
> >>  ...
> >>  int hdr_size = sizeof(struct udphdr) +
> >>  (skb->protocol == htons(ETH_P_IP) ?
> >>  sizeof(struct iphdr) : sizeof(struct ipv6hdr));
> >>  u8 tmp[hdr_size + RXE_BTH_BYTES];
> >>  ...
> >> }
> >
> >   pretty sure "sizeof" can be calculated at compile time so i don't
> > see a problem here.
>
> Yes, but skb->protocol is variable and sizeof(struct iphdr) !=
> sizeof(struct ipv6hdr)).  Is the compiler smart enough to just use the
> largest possible value?  The logic here is pretty similar to a union,
> which it of course wouldn't have any problems calculating the size of.

  ah, quite so, i didn't look closely enough.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: variant length array?

2016-04-05 Thread Robert P. J. Day

On Tue, 5 Apr 2016, Wenda Ni wrote:

> Hi all,
>
> I come across the following code in a kernel module code. It defines
> an array whose length is variant at runtime, depending on the actual
> inputs. It seems that kernel compiler supports this, which is
> obvious an error in the standard ANSI C. Do I have the correct
> understanding on it?
>
> Thank you.
>
>
> u32 rxe_icrc_hdr(struct rxe_pkt_info *pkt, struct sk_buff *skb)
> {
>  ...
>  int hdr_size = sizeof(struct udphdr) +
>  (skb->protocol == htons(ETH_P_IP) ?
>  sizeof(struct iphdr) : sizeof(struct ipv6hdr));
>  u8 tmp[hdr_size + RXE_BTH_BYTES];
>  ...
> }

  pretty sure "sizeof" can be calculated at compile time so i don't
see a problem here.

rday


-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Memory Management

2016-02-08 Thread Robert P. J. Day

Quoting sanjeev sharma :

> Hi,
>
> I would suggest you to go through the Linux Kernel book Robert Love which
> is simpler to understand.

   just a caution that that book is starting to show its age, even though
it's still really, really good. the memory management is probably still
fairly current, but i would compare all code snippets against the
current kernel just in case.

rday



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

should "get_user_pages()" really be phased out?

2016-01-04 Thread Robert P. J. Day


  poking around mm/gup.c at "get_user_pages()" and related routines,
and noticed this:

 * get_user_pages should be phased out in favor of
 * get_user_pages_locked|unlocked or get_user_pages_fast. Nothing
 * should use get_user_pages because it cannot pass
 * FAULT_FLAG_ALLOW_RETRY to handle_mm_fault.

so does that mean what it seems to mean ... that nothing outside of
memory management should call get_user_pages() directly? i can see
that some of those other routines are implemented in terms of
get_user_pages() -- does that mean that get_user_pages() should be
made static so that only those routines are allowed to call it, and
everyone else should invoke one of the other routines?

  just trying to understand the eventual desired fate of
get_user_pages().

rday

-- 

========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: how to reduce both vmlinuz size and modules?

2015-12-27 Thread Robert P. J. Day

On Sat, 26 Dec 2015, valdis.kletni...@vt.edu wrote:

> On Sat, 26 Dec 2015 10:39:04 -0500, "Robert P. J. Day" said:
>
> >   if i start with the latest git kernel repo, it *looks* like i
> > can use the /boot/config-4.2.8-200.fc22.x86_64 config file as a
> > starting point, copy it in as .config, then:
> >
> >  $ make allmodconfig
> >  $ make localmodconfig
>
> How much simpler could you make it? :)

  i'm not sure, that's why i asked. :-) i was pretty sure there was no
*single* make target that did what i wanted, i just want to make sure
i understand the semantics of the two targets above.

  as i read it (and, admittedly, i still need to read the code in more
detail), "make allmodconfig" will select as much as it possibly can as
modules so, in the end, i would have a functionally equivalent
bootable system with a smaller kernel, along with a zillion compiled
modules (most of which i don't need).

  the second make target would then leave the definition of the
vmlinux build alone, and simply reduce the module selection to what is
currently loaded. so as long as my understanding of those targets is
correct, that seems to be what i'm after.

> The place you're most likely to screw it up is to forget to plug in
> all your USB and other widgets at least once before the 'make
> localmodconfig' to make sure they get modprobed.

  i know, that's the fear, so i'm plugging in various devices i use
(like my android phone) just to see what modules kick in.

> As a practical matter, if 'make allmodconfig' had slightly different
> semantics, we could do better.  'allmod' has semantics of 'turn on
> every possible =m'. If there were a semantic of 'convert as many
> existing =y into =m, but *don't* convert =n into =m', we could do
> this and it would almost certainly be faster.
>
> boot distro kernel
> (plug in widgets)
> make localmodconfig
> boot into that kernel
> make mostlymodconfig
> boot
> plug in widgets
> make localmodconfig  *again*
>
> The reason it would be faster - a Fedora Rawhide kernel has 2,793
> =m, a 'allmodconfig' has 5,162 - but doing a 'localmodconfig' gets
> it down to 33 on my laptop (though admittedly I've made a lot of
> device drivers =y so they're part of vmlinux - but /sys/module tells
> me there's a max of 133 or so of those).  So after the first
> 'localmodconfig', you've gotten rid of probably 75% to 90% of the
> modules to build, and thus build time. It's probably faster to do 3
> builds like this than an allmod/mostlymod pair.
>
> Note that if you're *really* concerned about vmlinux size (like
> embedded devices), you'll want to make a second pass through all the
> =y, and see how many are system features you don't need, but which
> can't be modular. Things like SYSV shared memory and IPC, BSD
> process accounting, and so on...
>
> I wonder if adding a 'mostlymodconfig' to Kconfig would be
> worthwhile. Comments?

  i think that could be useful unless (as you point out) it can be
emulated easily with a couple other targets. anyway, time to give this
a try.

rday

-- 

Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: how to reduce both vmlinuz size and modules?

2015-12-27 Thread Robert P. J. Day

On Sat, 26 Dec 2015, valdis.kletni...@vt.edu wrote:

> On Sat, 26 Dec 2015 10:39:04 -0500, "Robert P. J. Day" said:
>
> >   if i start with the latest git kernel repo, it *looks* like i can
> > use the /boot/config-4.2.8-200.fc22.x86_64 config file as a starting
> > point, copy it in as .config, then:
> >
> >  $ make allmodconfig
> >  $ make localmodconfig
>
> How much simpler could you make it? :)
>
> The place you're most likely to screw it up is to forget to plug in
> all your USB and other widgets at least once before the 'make
> localmodconfig' to make sure they get modprobed.
>
> As a practical matter, if 'make allmodconfig' had slightly different
> semantics, we could do better.  'allmod' has semantics of 'turn on
> every possible =m'. If there were a semantic of 'convert as many
> existing =y into =m, but *don't* convert =n into =m', we could do
> this and it would almost certainly be faster.

  yeah, that's definitely what i'm after. i see no immediate way to
fake or emulate that.

rday

-- 

====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

how to reduce both vmlinuz size and modules?

2015-12-26 Thread Robert P. J. Day


  currently running latest version of fedora 23, with
4.2.8-200.fc22.x86_64 fedora kernel package, and i'm wondering about
the best way to both reduce the kernel size, and cut down on the
number of modules i'm building, based on what looks like combining a
couple of make targets.

  if i start with the latest git kernel repo, it *looks* like i can
use the /boot/config-4.2.8-200.fc22.x86_64 config file as a starting
point, copy it in as .config, then:

 $ make allmodconfig
 $ make localmodconfig

as i read it (and i could be mistaken), the first make would transform
as many "y" kernel selections to "m" as possible, while the second
would then remove any module config selections that are currently not
loaded.

  am i reading that correctly? is there a simpler way to do this?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

if i want powerpc "local bus" support, must i select CONFIG_FSL_LBC?

2015-12-07 Thread Robert P. J. Day


  trying to make a long story short, was handed an aging powerpc
MPC8360e system on which to place linux, along with a BSP that does in
fact generate a bootable kernel and filesystem. however, according to
this online page (and i am *not* in any way a powerpc expert):

http://cache.freescale.com/files/netcomm/doc/fact_sheet/MPC8360EFS.pdf

this processor has something called a "local bus", off of which on
this board hang things like DSP, FPGA and other things.

  during boot, i can see absolutely no mention of any of the devices
attached to this local bus, or even that the bus itself is recognized,
then i noticed that the .config file used to build this 3.14.29 kernel
does not select what looks like the appropriate kernel option FSL_LBC.

  if anyone out there is a powerpc expert, can you confirm that you
need to select that option (and hence compile in the source file
arch/powerpc/sysdev/fsl_lbc.c) to get that support?

  i'm puzzled only because, if that file is required for local bus
support, the people who gave us the BSP really should have turned it
on.

  thanks for any guidance.

rday

-- 

========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

viability of supporting interrupts in user space driver?

2015-11-19 Thread Robert P. J. Day


  some colleagues are considering implementing some user space drivers
that need to recognize and process interrupts. i'm aware of the
possibilities -- UIO, for example -- but other than the technical
possibility of doing that, can anyone provide feedback on the
viability or benchmarking of that?

  is there an example someone can point at that demonstrates the
goodness or not of such an approach? has anyone out there done this,
and lived to regret it in terms of performance? thanks.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: looking for decent, current online discussion of user-space drivers

2015-11-17 Thread Robert P. J. Day

On Tue, 17 Nov 2015, Anupam Kapoor wrote:

>
> >>>>> [2015-11-17T15:43:52+0530]: "Robert P. J. Day" (rpjday):
> ,[ rpjday ]
> | 
> | in particular, are there any nice examples of this that
> | can be downloaded, built and played with? thanks muchly.
> `
> there is snabbswitch (https://github.com/SnabbCo/snabbswitch) where
> folks have written 82599 (intel-10g card) driver in lua
> (https://github.com/SnabbCo/snabbswitch/tree/master/src/apps/intel)
>
> might be useful...

   h, yes, thanks for the link. just to keep track of what i
collect, i started a new wiki page:

http://www.crashcourse.ca/wiki/index.php/User_space_drivers

i'll add anything else that pops up that looks like it's useful.

rday

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

looking for decent, current online discussion of user-space drivers

2015-11-17 Thread Robert P. J. Day


  a colleague asks me about the implications of porting a pile of code
from a non-linux embedded OS to linux, and simply rewriting most of it
as user-space drivers, as opposed to a total rewrite to kernel code.
i'm in no way an authority on user-space drivers, so i'm looking for
any decent, up-to-date discussions, not so much on the technical
aspects, but more the *implications* of doing this.

  i'm aware of mmap(), and i'm reading up on UIO, and i've found a few
online pieces that look informative:

http://www.embedded.com/design/operating-systems/4401769/Device-drivers-in-user-space
http://www.enea.com/Documents/Resources/Whitepapers/Enea-User-Space-Drivers-in-Linux_Whitepaper_2013.pdf

so is there something that elaborates on both the pros and cons of
doing this? in particular, are there any nice examples of this that
can be downloaded, built and played with? thanks muchly.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: is there a reason "usbhid.quirks" parameter is not root writable?

2015-11-13 Thread Robert P. J. Day

On Fri, 13 Nov 2015, Bjørn Mork wrote:

> "Robert P. J. Day" <rpj...@crashcourse.ca> writes:
> > On Thu, 12 Nov 2015, Greg KH wrote:
> >
> >> You can add a runtime quirk to the device itself when it shows up in
> >> sysfs for the hid driver.  Use that instead of the module parameter for
> >> that specific device.
> >
> >   sorry, i'm not sure what you're suggesting here.
>
> I don't know if this was what Greg meant, but you can always use
>
>  /sys/bus/usb/drivers/usbhid/unbind
>
> to unbind the device from the usbhid driver.  Then you can manually
> bind it to some other driver supporting the same device using the
> same mechanism (with s/un// of course), or load another supporting
> driver to make it probe and bind the device.

  ah, got it, thanks. i've never done that but the concept seems easy
enough.

> Hmm, I was going to point you to the file documenting bind/unbind
> for the usb bus, but it doesn't seem to exist?  There you have a
> task for someone wanting to improve the docs :)

  and that's one of the things i mention occasionally when newbies ask
how to get started working on the kernel. write/improve the docs. what
a perfect example.

> Anyway, it goes like this: Look at the device driver binding in sysfs:
>
> $ ls -l /sys/bus/usb/drivers/usbhid
> total 0
> lrwxrwxrwx 1 root root0 Nov 13 09:06 4-4:1.0 -> 
> ../../../../devices/pci:00/:00:1d.7/usb4/4-4/4-4:1.0
> --w--- 1 root root 4096 Nov 13 09:06 bind
> lrwxrwxrwx 1 root root0 Nov 13 09:06 module -> ../../../../module/usbhid
> -rw-r--r-- 1 root root 4096 Nov 13 09:06 new_id
> -rw-r--r-- 1 root root 4096 Nov 13 09:06 remove_id
> --w--- 1 root root 4096 Nov 13 09:06 uevent
> --w--- 1 root root 4096 Nov 13 09:06 unbind
>
>
> Unbind the device you want to move somewhere else:
>
> $ echo 4-4:1.0 >/sys/bus/usb/drivers/usbhid/unbind
>
> Bind it to 'otherdriver':
>
> $ echo 4-4:1.0 >/sys/bus/usb/drivers/'otherdriver'/bind
>
> (wich will only succeed of that driver's probe succeeds, of course.  If
> you need to add a device ID to another driver, then do that using
> 'new_id' instead.  Which will trigger automatic probing of 'free'
> devices)

  thank you kindly, i'll give this a shot.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

is there a reason "usbhid.quirks" parameter is not root writable?

2015-11-12 Thread Robert P. J. Day


  short form: is there some reason that the usbhid "quirks" parameter
is not by default compiled to be writable in case you wanted to adjust
those values on a running system?

  long form: i have a USB device that, sadly, is automatically claimed
by the usbhid driver upon insertion, and i want to prevent that so it
behaves as a regular USB device. from what i've read, the solution is
to, at boot time, add the kernel command line parameter:

  usbhid.quirks=0x2123:0x1010:0x04

that's fine if i want to reboot so that that takes effect, but it
would of course be convenient if i could add that info to
/sys/module/usbhid/parameters/quirks at run-time. currently, on my
fedora 22 system:

$ cat /sys/module/usbhid/parameters/quirks
(null),(null),(null),(null)
$

with permissions:

$ ls -l /sys/module/usbhid/parameters/quirks
-r--r--r--. 1 root root 4096 Nov 12 02:41 /sys/module/usbhid/parameters/quirks
$

and i can see in drivers/hid/usbhid/hid-core.c the fact that that
array is defined as non-writable:

/* Quirks specified at module load time */
static char *quirks_param[MAX_USBHID_BOOT_QUIRKS];
module_param_array_named(quirks, quirks_param, charp, NULL, 0444);
MODULE_PARM_DESC(quirks, "Add/modify USB HID quirks by specifying "
" quirks=vendorID:productID:quirks"
" where vendorID, productID, and quirks are all in"
" 0x-prefixed hex");

so the obvious(?) question is, is there some reason that that
parameter is defined as read-only rather than, say, writable by root?
would it not be useful to be able to modify that parameter at
run-time? or is there something about that parameter for which that
would be a really bad idea?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday




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

Re: is there a reason "usbhid.quirks" parameter is not root writable?

2015-11-12 Thread Robert P. J. Day

On Thu, 12 Nov 2015, Greg KH wrote:

> On Thu, Nov 12, 2015 at 03:15:41AM -0700, Robert P. J. Day wrote:
> >
> >   short form: is there some reason that the usbhid "quirks" parameter
> > is not by default compiled to be writable in case you wanted to adjust
> > those values on a running system?
> >
> >   long form: i have a USB device that, sadly, is automatically claimed
> > by the usbhid driver upon insertion, and i want to prevent that so it
> > behaves as a regular USB device. from what i've read, the solution is
> > to, at boot time, add the kernel command line parameter:
> >
> >   usbhid.quirks=0x2123:0x1010:0x04
> >
> > that's fine if i want to reboot so that that takes effect, but it
> > would of course be convenient if i could add that info to
> > /sys/module/usbhid/parameters/quirks at run-time. currently, on my
> > fedora 22 system:
> >
> > $ cat /sys/module/usbhid/parameters/quirks
> > (null),(null),(null),(null)
> > $
> >
> > with permissions:
> >
> > $ ls -l /sys/module/usbhid/parameters/quirks
> > -r--r--r--. 1 root root 4096 Nov 12 02:41 
> > /sys/module/usbhid/parameters/quirks
> > $
> >
> > and i can see in drivers/hid/usbhid/hid-core.c the fact that that
> > array is defined as non-writable:
> >
> > /* Quirks specified at module load time */
> > static char *quirks_param[MAX_USBHID_BOOT_QUIRKS];
> > module_param_array_named(quirks, quirks_param, charp, NULL, 0444);
> > MODULE_PARM_DESC(quirks, "Add/modify USB HID quirks by specifying "
> > " quirks=vendorID:productID:quirks"
> > " where vendorID, productID, and quirks are all in"
> > " 0x-prefixed hex");
> >
> > so the obvious(?) question is, is there some reason that that
> > parameter is defined as read-only rather than, say, writable by root?
> > would it not be useful to be able to modify that parameter at
> > run-time? or is there something about that parameter for which that
> > would be a really bad idea?
>
> You can add a runtime quirk to the device itself when it shows up in
> sysfs for the hid driver.  Use that instead of the module parameter for
> that specific device.

  sorry, i'm not sure what you're suggesting here.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: Safety in Kernel Development

2015-08-18 Thread Robert P. J. Day

On Tue, 18 Aug 2015, Kenneth Adam Miller wrote:

 Ok- so I know that C is the defacto standard for kernel
 development...

  and that's probably where you should have stopped typing. :-)

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: how it the linux implementation of double linked lists useful

2015-08-02 Thread Robert P. J. Day

On Sun, 2 Aug 2015, Ahmed Soliman wrote:

 while reading through linux/list.h I noticed that the linked list
 structure is really simple with only pointer to the previous node and
 pointer to next node with no other data (It can't handle anything
 inside it ) I started to wonder how such linked list can be useful to
 the kernel or (useful in general) !
 thanks

  i wrote a tutorial about that once:

http://www.crashcourse.ca/introduction-linux-kernel-programming/intermission-lets-talk-about-linked-lists-and-containerof-free

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: What can I do if I sent a wrong patch?

2015-07-19 Thread Robert P. J. Day

On Sun, 19 Jul 2015, Navy wrote:

 Hello,

 A mistake was found after I sent the patch to mentors. What Can I do
 to make up the fault?

  first, if they're truly mentors, they should check the patch
themselves and catch the error. otherwise, they're not really doing
their job as mentors.

  second, you need to self-examine what you failed to do properly to
have sent in a bad patch.

  i doubt you've done any real harm; the linux kernel has lots of
checking up the hierarchy so that a truly damaging patch is rarely
going to get into the source tree.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: When to resend a patchset?

2015-07-19 Thread Robert P. J. Day

On Sun, 19 Jul 2015, Greg KH wrote:

 On Sat, Jul 18, 2015 at 04:11:30PM +0200, Ricardo Ribalda Delgado wrote:
  Hello
 
  Usually I was taking the approach of pinging a patch after 21 days of
  inactivity.
 
  This has worked ok  in the past, but the last time I have done it I
  was told that the merge window was open and that nothing could be done
  at that time.
 
  Is there a written guideline to know when to resend/ping a patch?
  How can I figure out the current development status of the kernel?

 Look at the release that is happening this week, that will tell you
 the status.  Take a look at Documentation/development_process/ for
 more details than you ever wanted to know :)

  it's just eerie how any discussion involving greg KH typically ends
with the phrase, more details than you ever wanted to know. :-)

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: About Low Hanging Fruits

2015-07-13 Thread Robert P. J. Day

On Mon, 13 Jul 2015, valdis.kletni...@vt.edu wrote:

 On Mon, 13 Jul 2015 12:13:28 +0530, Mayur Patil said:

I just want to know like other Open source projects is there a thing in
  linux kernel as Low hanging fruits.

 The Linux kernel has been worked over by professional programmers
 for more than a decade, and as a result the number of things that
 can be attacked by a relatively unskilled newcomer is fairly low.

 Your best place to start is probably under drivers/staging, where we
 put all the stuff that's *not* up to standards yet.  Each driver
 should have a TO-DO file describing what needs doing, and Greg HK is
 always willing to take checkpatch style fixups for the staging tree
 (many other maintainers *don't* want style patches that aren't
 connected to other work - if there's other active work, they can
 introduce merge conflicts, and if nobody's working on something,
 it's best to not touch stable code...)

  actually, one area of low-hanging fruit is the Documentation/
directory, which could always use some attention. documentation is
always getting out of date, so pick a subsystem and clean up the docs.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

working with linux-next ... must tags be fetched separately?

2015-06-28 Thread Robert P. J. Day


  perusing the current instructions on how to work with linux-next
here:

https://www.kernel.org/doc/man-pages/linux-next.html

and i'm puzzled by this part of the instructions:

 Fetch linux-next plus tags

$ git fetch linux-next
...
$ git fetch --tags linux-next
...

is it really necessary to run two separate fetch commands? from the
man page for git-fetch, one reads:

   -t, --tags
   Fetch all tags from the remote (i.e., fetch remote tags refs/tags/* 
into local tags with
   the same name), in addition to whatever else would otherwise be 
fetched.

so would it not be sufficient to run simply:

$ git fetch --tags linux-next

or am i misreading something?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: working with linux-next ... must tags be fetched separately?

2015-06-28 Thread Robert P. J. Day

On Sun, 28 Jun 2015, Harsh Jain wrote:

 Hi,

 git fetch --tags linux-next

 Will only fetch the tags not changed files content/data.

 To fetch file changes
 git fetch linux-next

 Is required.



 On 28 June 2015 14:59:15 GMT+05:30, Robert P. J. Day 
 rpj...@crashcourse.ca wrote:

   perusing the current instructions on how to work with linux-next
 here:
 https://www.kernel.org/doc/man-pages/linux-next.html
 and i'm puzzled by this part of the instructions:
  Fetch linux-next plus tags
 $ git fetch linux-next
 ...
 $ git fetch --tags linux-next
 ...
 is it really necessary to run two separate fetch commands? from the
 man page for git-fetch, one reads:
-t, --tags
Fetch all tags from the remote (i.e., fetch remote tags 
 refs/tags/* into local tags with
the same name), in addition to whatever else would otherwise be 
 fetched.
 so would it not be sufficient to run simply:
 $ git fetch --tags linux-next
 or am i misreading something?
 rday

  that suggests that the man page is slightly misleading, given that
it clearly states that --tags will fetch tags, in addition to
whatever else would otherwise be fetched. or is there a different way
to read that phrase?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: About guiding hello world module submission

2015-06-24 Thread Robert P. J. Day

On Wed, 24 Jun 2015, Mayur Patil wrote:

 Hi All,

    I am conducting one workshop at FUDCon in which I am trying to
 teach how to write and send your first linux kernel device driver.
 Could please suggest me the place where I can guide the students to
 send the device driver?

  once upon a time, i wrote an (admittedly-dated) online course on how
to get started with kernel programming (and, yes, it needs updating
:-P):

http://crashcourse.ca/introduction-linux-kernel-programming/introduction-linux-kernel-programming

ignore the $39 reference, the course has been publicly available for
free for a while.

  on the second point -- how to *send* that driver to the kernel --
don't you kind of need a rationale for why you're working on a driver
that isn't in the kernel already? i suspect that if you're already
competent enough to be writing a driver for something that isn't in
the kernel, you probably already know the protocol for submitting it,
no?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: About head of kernel linked list structure

2015-05-07 Thread Robert P. J. Day

On Thu, 7 May 2015, Huaicheng Li wrote:

 Hi Robert,

 You got my point and I’m sorry for not stating it in a clear way.
 You are right about the prev-to-left and next-to-right when
 drawing the line. At that time, I just wanted to show which node
 they were pointing at.  Anyway, you solved my puzzle. Also thanks
 for your excellent article.

  it's a moderately common mistake to not realize that the head of a
list is represented by just another struct list_head like all the
other elements in the list, but it's a special list_head in the sense
that it does ***not*** represent a valid enclosing data payload, and
should never be dereferenced.

  the way i normally demonstrate this is to show the following macro
from include/linux/list.h:

/**
 * list_for_each-   iterate over a list
 * @pos:the struct list_head to use as a loop cursor.
 * @head:   the head for your list.
 */
#define list_for_each(pos, head) \
for (pos = (head)-next; pos != (head); pos = pos-next)

  note well how iteration over a list starts from (head)-next and
continues until returning back to (head) while *not* including that
last address to be dereferenced.

  this also has the (obvious) consequence that you can never forget
which element in a list is the head; otherwise, you'll never know
which element you're not supposed to dereference.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: About head of kernel linked list structure

2015-05-06 Thread Robert P. J. Day

On Wed, 6 May 2015, Huaicheng Li wrote:

In my understanding, the head initialised using LIST_HEAD_INIT or
defined by LIST_HEAD corresponds to no *real* data field.

correct. a better way to describe it would be that it corresponds to
no real enclosing payload, so it should never be dereferenced to get
to said payload.

But it *does* have its own _next_ and _prev_ pointers. The _next_
pointer points to the first real node in the doubly linked list, and
the _prev_ pointer points to the last real node.

so far, so good -- by real, you mean list heads that actually
correspond to an enclosing payload.

I'm wondering if the picture shown at the very bottom of
http://kernelnewbies.org/FAQ/LinkedLists is wrong about this.
Because

I believe head's _prev_ should point to the last node, which is at
the very right. And the last node's _next_ should point to the head.
Just as shown like the red line.

Am I right?

it looks fine to me, although my standard is to show next pointers
going to the right, and prev to the left, but this way looks fine.
maybe i'm misunderstanding your objection.

i once wrote a tutorial on LLs:

http://www.crashcourse.ca/introduction-linux-kernel-programming/intermission-lets-talk-about-linked-lists-and-containerof-free

rday

Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday

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

Re: running queue processes

2015-05-04 Thread Robert P. J. Day

On Sun, 3 May 2015, Nicholas Krause wrote:



 On May 3, 2015 9:16:27 AM EDT, Ruben Safir ru...@mrbrklyn.com wrote:
 On 05/03/2015 08:47 AM, Nicholas Krause wrote:
  remember there being information about this topic being in the Linux
 programming interface in chapters 26 through 28. Furthermore find a
 copy of this book as it's a rather good reference for when you need
 questions like this answered.
 
 
 which book?

 The book is called the Linux programming interface and the chapters
 related to this question are chapters 26 or 27 I believe.

  nick, this is another reason your contributions to this forum (and
pretty much every other one you're on) are so frequently valueless --
you rarely give a complete or useful answer.

  i suspect the book you're referring to is michael kerrisk's the
linux programming interface, http://man7.org/tlpi/index.html (a book
to which i have actually contributed corrections,
http://man7.org/tlpi/errata/index.html), which is a reference you
*could* have provided but, instead, you chose to leave just this
maddeningly half-vague reference to a book and some chapter numbers.

  it's an annoying habit with you, nick -- someone asks a well-formed
and specific question and, because you always want to be the first one
to jump in with an answer to burnish your credentials, your reply is
typically something like, i think there's a system call that does
what you want, you should look it up.

  your eagerness to leap in and be the first one to be helpful
typically means your contributions are vague, vacuous, incomplete and,
in some cases, simply wrong. but rather than take the time to
research the question so that your response is actually *helpful*, you
prefer to contribute little more than, i think this thing might help
what you're working on, you should check the man page.

  you're not doing your reputation any favours.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: Suggested environments for kernel development

2015-05-03 Thread Robert P. J. Day

On Sun, 3 May 2015, Greg KH wrote:

 On Sun, May 03, 2015 at 06:11:35PM +0100, Lewis Clark wrote:
  I would really like to know how you guys do your kernel development.
  What distro do you use and whats the process?
 
  I’m very comfortable with debian, but i’ve heard it’s not the easiest
  distro to build kernels for as you need to build to a .deb and apply
  it that way.

 Not at all, any community-based distro is usually good for kernel
 development, pick one you feel comfortable with and use it.

  if you're going to just manually install the new kernel, then it
makes precious little difference. on the other hand, if you really
want to go through the packaging, then you can run one of:

  $ make rpm-pkg
  $ make deb-pkg

other than that, as greg suggests, any even *remotely* current distro
should work just fine.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[PATCH] .gitignore: Simplify Git ignoring generated directories.

2015-04-29 Thread Robert P. J. Day


Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca

---

  am i correct in assuming that this change, first of all, makes it
clear that only directories are involved and, also, that one can
simply ignore all directories with the name generated?

diff --git a/.gitignore b/.gitignore
index 4ad4a98..9301b0c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -68,9 +68,8 @@ Module.symvers
 #
 # Generated include files
 #
-include/config
-include/generated
-arch/*/include/generated
+include/config/
+generated/

 # stgit generated dirs
 patches-*

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

1 2 3 >

1 - 100 of 292 matches

Mail list logo