- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

What Next After Char, Block, Serial & Parallel Drivers
by Sasha Mckinsey Aug. 11, 2015

Aug. 11, 2015

Hello, Finally I can say I have completed learning the following (to a certain extent) -C and Data structures -Operating system concepts ( covered in my undergrad course) -Linux kernel Development - Robert Love -Linux Device Drivers - Partially (just finished Char, block, serial & parallel ) A book called "Essential Linux Device Drivers" - It looked rich a first look but I could go anywhere with it considering I didn't have the required Hardware. I have now cut my teeth into some bit of kernel but still I am not sure where to go from here. I know things but I am not happy or satisfied with what I now. I don't have the feel of a professional device driver programmer. Here are my questions - two different questions and necessarily not connected to each other What should be the next steps besides looking for a job. Getting a new hardware to write a driver I guess is not feasible all the time. Any ideas During my Linux journey i realized Linux network stack development interests me alot but a friend of mine told me to stay away from it as its very vast and would consume me. Any ideas how should i approach it if I want to learn it from practical point of view. I am not looking for the names of books or resources I have all of them including the book understanding Linux network internals. I want to learn it from a practical point of view where in I can be actively involved unlike my status today in the world of device drivers. Thanks!

3 4

[PATCH v2 2/3] kobject: export kset_find_obj() to be used from modules
by Gabriel L. Somlo Aug. 11, 2015

Aug. 11, 2015

From: "Gabriel Somlo" <somlo(a)cmu.edu> Signed-off-by: Gabriel Somlo <somlo(a)cmu.edu> --- lib/kobject.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/kobject.c b/lib/kobject.c index 0554077..8f07202 100644 --- a/lib/kobject.c +++ b/lib/kobject.c @@ -847,6 +847,7 @@ struct kobject *kset_find_obj(struct kset *kset, const char *name) spin_unlock(&kset->list_lock); return ret; } +EXPORT_SYMBOL(kset_find_obj); static void kset_release(struct kobject *kobj) { -- 2.4.3

1 0

[PATCH v2 0/3] SysFS driver for QEMU fw_cfg device
by Gabriel L. Somlo Aug. 11, 2015

Aug. 11, 2015

From: "Gabriel Somlo" <somlo(a)cmu.edu> This patch set makes QEMU fw_cfg blobs available for viewing (read-only) via SysFS. New since v1: 1/3: - renamed sysfs path components: s/fw_cfg/qemu_fw_cfg/g, at Greg's suggestion s/by_select/by_key/g since it feels a bit more intuitive - attribute "select" renamed to "key", along the same train of thought. - renamed actual source file from "fw_cfg.c" to "qemu_fw_cfg.c" and doc file in Documentation/ABI/testing to "sysfs-firmware-qemu_fw_cfg" - s/uintXX_t/uXX/g, at Greg's suggestion - using named identifiers to initialize access mode table (static struct fw_cfg_access fw_cfg_modes[]) per Greg's suggestion - removed redundant "capable(CAP_SYS_ADMIN)" checks (per Greg's feedback) 2/3: - EXPORT_SYMBOL(kset_find_obj) statement moved immediately after kset_find_obj() definition. Re. 'struct device' vs. straight-up kobject: I dug around a bit, and found a bunch of stuff under /sys/devices (such as e.g. /sys/devices/virtual/dmi and /sys/devices/platform/applesmc) The first one is particularly interesting, as it presents a somewhat different view of the same internal information displayed by /sys/firmware/dmi/, only /sys/devices/virtual/dmi looks more "cooked", in that it exposes individual fields of the several different DMI tables. None of the subfolders of /sys/devices/... appears to facilitate access to the "raw blobs" contained by the respective devices represented there. Even applesmc (the other device with which I'm somewhat familiar) does a lot of "cooking" of the values held by the device. So, at the end of the day, I want the information I expose about fw_cfg to look more like /sys/firmware/dmi than like /sys/devices/virtual/dmi in that I have a bunch of cached metadata attributes for each of the blobs, and want to offer access to the raw blob data, and there's no rhyme or reason to the actual internals of any of the blobs, so offering a "cooked" view like in /sys/devices/... doesn't feel like the best fit... Obviously, I may be totally wrong... :) Lastly, re. Greg's comment on patch 3/3: > Shouldn't all of this be done in userspace with the symlinks and all? > It seems like you are trying to duplicate the /dev/block/by-name and > such. Policy decisions like symlinks and naming should be done there, > in userspace, and not directly in sysfs if at all possible. OK, so here's the "pseudo-bash" equivalent of what this patch does: #upon successful qemu_fw_cfg.ko insertion BY_KEY="/sys/firmware/qemu_fw_cfg/by_key" BY_NAME="/sys/firmware/qemu_fw_cfg/by_name" mkdir -p $BY_NAME for KEY in $(ls $BY_KEY); do FILE=$(cat $BY_KEY/$KEY/name) [ mkdir -p $BY_NAME/$(dirname $FILE) ] || continue pushd $BY_NAME/$(dirname $FILE) ln -s $BY_KEY/$KEY $(basename $FILE) popd done Note how it MAY fail to mkdir, in which case it skips to the next key, or it MAY fail to create the symlink, in which case it just moves on to the next key as well. Again, the fw_cfg device doesn't have any notion of nested directories, it just parrots back some random string someone choose as a name for a given blob, but these strings typically contain slash-separated ASCII which "looks like" it "could" be a path name :) If there's a reasonable way to do this dynamically, immediately upon insertion of the qemu_fw_cfg.ko module, patches 2/3 and 3/3 could be dropped. But before that, I'd appreciate a pointer to how/where this can be done in userspace. Would it be available e.g. during early boot, early enough to e.g. raw-dump an ASCII blob containing shell variable definitions (e.g. to set hostname on the guest, etc ?) Doing it as part of the qemu_fw_cfg.ko module itself has the advantage of it being available immediately, without anything having to "watch" for the module being inserted. But if userspace is the standard, "canonical" place to do something like this, I'd be happy to give it a try, once I find the right tree to bark up on... :) Thanks much, Gabriel Old "cover-letter" blurb for v1: > Several different architectures supported by QEMU are set up with a > "firmware configuration" (fw_cfg) device, used to pass configuration > "blobs" into the guest by the host running QEMU. > > Historically, these config blobs were mostly of interest to the guest > BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via > the command line, which makes them potentially interesting to userspace > (e.g. for passing early boot environment variables, etc.). > > In addition to cc-ing the people and lists indicated by get-maintainer.pl, > I've added a few extra lists suggested by Matt Fleming on the qemu-devel > list, as well as the qemu-devel list itself. > > Also cc-ing kernelnewbies, as this is my very first kenel contribution, > so please go easy on me for whatever silly n00b mistakes I might have still > missed, in spite of trying hard to do all my homework properly... :) > > The series consists of three patches: > > 1/3 - probes for the qemu fw_cfg device in locations known to work on > the supported architectures, in decreasing order of "likelihood". > > While it *may* be possible to detect the presence of fw_cfg via > acpi or dtb (on x86 and arm, respectively), there's no way I know > of attempting that on sun4 and ppc/mac, so I've stuck with simply > probing (the fw_cfg_modes[] structure and fw_cfg_io_probe() function) > in fw_cfg.c. I could use some advice on how else that could be > done more elegantly, if needed. > > Upon successfully detecting a present fw_cfg device, we set up > /sys/firmware/fw_cfg/by_select entries for each blob available > on the fw_cfg device. > > 2/3 - export kset_find_obj() (in lib/kobject.c) for use with modules, > which will come in handy in patch #3, below. > > 3/3 - add a "user friendly" way of listing fw_cfg blobs by name rather > than by unique selector key. > > Since fw_cfg blob names are traditionally set up to look like > path names, it would be nice to mirror that fact when displaying > them under /sys/firmware/fw_cfg in a "by_name" subdirectory. > > I'm using ksets to reflect subdirectories matching "dirname" > tokens separated by '/' within each fw_cfg blob "filename", > and symlinks into the "by_select" subdirectory for each "basename". > > Since the fw_cfg device doesn't enforce that blob names have > well-behaved and non-conflicting names, it is possible (though > unlikely) that there will be blobs named: > > "etc/foo/bar" > and > "etc/foo" > > where "foo" will try to be both a subdirectory AND a symlink under > /sys/firmware/fw_cfg/by_name/etc/. In such an event, the latter > fw_cfg blob will simply be skipped from having an entry created > under the user-friendly "by_name" subdirectory, remaining listed > only as an entry under the "by_select" subdirectory. > > I have tested this on x86_64 and armv7hl+lpae kernels. Builds and installs > OK as both a module and linked directly into the kernel. Gabriel Somlo (3): firmware: introduce sysfs driver for QEMU's fw_cfg device kobject: export kset_find_obj() to be used from modules firmware: fw_cfg: create directory hierarchy for fw_cfg file names .../ABI/testing/sysfs-firmware-qemu_fw_cfg | 210 ++++++++ drivers/firmware/Kconfig | 10 + drivers/firmware/Makefile | 1 + drivers/firmware/qemu_fw_cfg.c | 560 +++++++++++++++++++++ lib/kobject.c | 1 + 5 files changed, 782 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg create mode 100644 drivers/firmware/qemu_fw_cfg.c -- 2.4.3

1 2

Next Steps After Char, Block, Serial & Parallel Drivers
by Sasha Mckinsey Aug. 11, 2015

Aug. 11, 2015

Sending the email again as the previous message was unreadable due to rich text...apologies! Hello, Finally I can say I have completed learning the following (to a certain extent) -C and Data structures -Operating system concepts ( covered in my undergrad course) -Linux kernel Development - Robert Love -Linux Device Drivers - Partially (just finished Char, block, serial & parallel ) A book called "Essential Linux Device Drivers" - It looked rich a first look but I could go anywhere with it considering I didn't have the required Hardware. I have now cut my teeth into some bit of kernel but still I am not sure where to go from here. I know things but I am not happy or satisfied with what I now. I don't have the feel of a professional device driver programmer. Here are my questions - two different questions and necessarily not connected to each other What should be the next steps besides looking for a job. Getting a new hardware to write a driver I guess is not feasible all the time. Any ideas During my Linux journey i realized Linux network stack development interests me alot but a friend of mine told me to stay away from it as its very vast and would consume me. Any ideas how should i approach it if I want to learn it from practical point of view. I am not looking for the names of books or resources I have all of them including the book understanding Linux network internals. I want to learn it from a practical point of view where in I can be actively involved unlike my status today in the world of device drivers. Thanks!

1 0

Smatch installation error
by Shraddha Barke Aug. 11, 2015

Aug. 11, 2015

I tried to install smatch but I'm getting some errors: First I did : git clone git://repo.or.cz/smatch.git Then : cd smatch When I run : make .. I get the following error Makefile:107: Your system does not have libgtk2, disabling test-inspect LINK sparse-llvm /usr/bin/ld: cannot find -ledit collect2: error: ld returned 1 exit status Makefile:211: recipe for target 'sparse-llvm' failed make: *** [sparse-llvm] Error 1 So I tried to install : sudo apt-get install libgtk2.0-dev which gives the error: Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libgtk2.0-dev : Depends: libglib2.0-dev (>= 2.27.3) but it is not going to be installed Depends: libgdk-pixbuf2.0-dev (>= 2.21.0) but it is not going to be installed Depends: libpango1.0-dev (>= 1.20) but it is not going to be installed Depends: libatk1.0-dev (>= 1.29.2) but it is not going to be installed Depends: libcairo2-dev (>= 1.6.4-6.1) but it is not going to be installed E: Unable to correct problems, you have held broken packages. Any help? Thanks in advance :)

2 1

[OT]Is there any good books which introduce X86_64 architecture?
by Nan Xiao Aug. 11, 2015

Aug. 11, 2015

Hi all, This message may be off-topic, please excuse me! Now I am studying and maintaining some device drivers. So I want to know whether there are some good books introduce X86_64 hardware architecture except the manual? Such as IO, MMU, interrupt handler, etc. Thanks very much in advance! Best Regards Nan Xiao

1 0

[PATCH] kobject: move EXPORT_SYMBOL() macros next to corresponding definitions
by Gabriel Somlo Aug. 10, 2015

Aug. 10, 2015

Move EXPORT_SYMBOL() macros in kobject.c from the end of the file next to the function definitions to which they belong. Signed-off-by: Gabriel Somlo <somlo(a)cmu.edu> --- On Mon, Aug 10, 2015 at 11:54:00AM -0700, Greg KH wrote: > > > > > > > > EXPORT_SYMBOL(kset_register); > > > > EXPORT_SYMBOL(kset_unregister); > > > > +EXPORT_SYMBOL(kset_find_obj); > > > > > > checkpatch doesn't like this for obvious reasons :) > > > > When I run checkpatch on this one, it comes back fine. Could you > > please elaborate ? > > > > [staging]$ scripts/checkpatch.pl > > 0002-kobject-export-kset_find_obj-to-be-used-from-modules.patch > > total: 0 errors, 0 warnings, 4 lines checked > > > > 0002-kobject-export-kset_find_obj-to-be-used-from-modules.patch has no > > obvious style problems and is ready for submission. > > EXPORT_SYMBOL() should be below the function definition itself, not at > the bottom of the file. Odd that checkpatch doesn't catch this when > done in this manner, it will if you run it on the whole file after your > patch is applied (along with the existing problems.) BTW, when I did that, I was merely trying to immitate what was already in lib/kobject.c. So here's making sure the next person won't get confused the same way I did... :) Thanks much, --Gabriel lib/kobject.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/lib/kobject.c b/lib/kobject.c index 3e3a5c3..0554077 100644 --- a/lib/kobject.c +++ b/lib/kobject.c @@ -568,6 +568,7 @@ void kobject_del(struct kobject *kobj) kobject_put(kobj->parent); kobj->parent = NULL; } +EXPORT_SYMBOL(kobject_del); /** * kobject_get - increment refcount for object. @@ -584,6 +585,7 @@ struct kobject *kobject_get(struct kobject *kobj) } return kobj; } +EXPORT_SYMBOL(kobject_get); static struct kobject * __must_check kobject_get_unless_zero(struct kobject *kobj) { @@ -675,6 +677,7 @@ void kobject_put(struct kobject *kobj) kref_put(&kobj->kref, kobject_release); } } +EXPORT_SYMBOL(kobject_put); static void dynamic_kobj_release(struct kobject *kobj) { @@ -803,6 +806,7 @@ int kset_register(struct kset *k) kobject_uevent(&k->kobj, KOBJ_ADD); return 0; } +EXPORT_SYMBOL(kset_register); /** * kset_unregister - remove a kset. @@ -815,6 +819,7 @@ void kset_unregister(struct kset *k) kobject_del(&k->kobj); kobject_put(&k->kobj); } +EXPORT_SYMBOL(kset_unregister); /** * kset_find_obj - search for object in kset. @@ -1051,10 +1056,3 @@ void kobj_ns_drop(enum kobj_ns_type type, void *ns) kobj_ns_ops_tbl[type]->drop_ns(ns); spin_unlock(&kobj_ns_type_lock); } - -EXPORT_SYMBOL(kobject_get); -EXPORT_SYMBOL(kobject_put); -EXPORT_SYMBOL(kobject_del); - -EXPORT_SYMBOL(kset_register); -EXPORT_SYMBOL(kset_unregister); -- 2.4.3

1 0

Re: [PATCH 1/3] firmware: introduce sysfs driver for QEMU's fw_cfg device
by Greg KH Aug. 10, 2015

Aug. 10, 2015

On Mon, Aug 10, 2015 at 03:02:22PM -0400, Gabriel L. Somlo wrote: > Mainly, qemu's fw_cfg is a read-only "device", so one wouldn't ever > care to try writing anything to it. /sys/firmware/... feels like a fit > because fw_cfg contains binary blobs originally meant to be used by > the bios (it's how SeaBIOS and OVMF pull smbios and acpi tables out of > the host and set them up in guest memory before booting the guest kernel, > as one of the many examples). > > The most similar example (and the existing driver I used as an example > during implementation) is dmi-sysfs.c, which also exposes all the > metadata for each smbios table as numeric (or string) read-only attributes, > and has a "raw" attribute which allows dumping each table in its > entirety. Same thing here -- I want to expose the name, size, and > select key for each blob, but also allow access to the "payload", i.e. > the blob itself. That's great, and you can have these "blobs" be an attribute for a struct device. Just using a "raw" kobject as you are is hard, as you have seen, and messy. Making it a "real" device makes this all much easier and simpler. Now if you want to keep things in /sys/firmware/ that's another issue, and would have to stay as a kobject. so maybe it does need to remain, need to think about that... thanks, greg k-h

1 0

Re: [PATCH 2/3] kobject: export kset_find_obj() to be used from modules
by Greg KH Aug. 10, 2015

Aug. 10, 2015

On Mon, Aug 10, 2015 at 02:43:10PM -0400, Gabriel L. Somlo wrote: > On Mon, Aug 10, 2015 at 11:33:04AM -0700, Greg KH wrote: > > On Mon, Aug 10, 2015 at 12:31:19PM -0400, Gabriel L. Somlo wrote: > > > From: "Gabriel Somlo" <somlo(a)cmu.edu> > > > > > > Signed-off-by: Gabriel Somlo <somlo(a)cmu.edu> > > > --- > > > lib/kobject.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/lib/kobject.c b/lib/kobject.c > > > index 3e3a5c3..f9754a0 100644 > > > --- a/lib/kobject.c > > > +++ b/lib/kobject.c > > > @@ -1058,3 +1058,4 @@ EXPORT_SYMBOL(kobject_del); > > > > > > EXPORT_SYMBOL(kset_register); > > > EXPORT_SYMBOL(kset_unregister); > > > +EXPORT_SYMBOL(kset_find_obj); > > > > checkpatch doesn't like this for obvious reasons :) > > When I run checkpatch on this one, it comes back fine. Could you > please elaborate ? > > [staging]$ scripts/checkpatch.pl > 0002-kobject-export-kset_find_obj-to-be-used-from-modules.patch > total: 0 errors, 0 warnings, 4 lines checked > > 0002-kobject-export-kset_find_obj-to-be-used-from-modules.patch has no > obvious style problems and is ready for submission. EXPORT_SYMBOL() should be below the function definition itself, not at the bottom of the file. Odd that checkpatch doesn't catch this when done in this manner, it will if you run it on the whole file after your patch is applied (along with the existing problems.) But this is a minor issue, see my other review first... greg k-h

2 1

[PATCH 2/3] kobject: export kset_find_obj() to be used from modules
by Gabriel L. Somlo Aug. 10, 2015

Aug. 10, 2015

From: "Gabriel Somlo" <somlo(a)cmu.edu> Signed-off-by: Gabriel Somlo <somlo(a)cmu.edu> --- lib/kobject.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/kobject.c b/lib/kobject.c index 3e3a5c3..f9754a0 100644 --- a/lib/kobject.c +++ b/lib/kobject.c @@ -1058,3 +1058,4 @@ EXPORT_SYMBOL(kobject_del); EXPORT_SYMBOL(kset_register); EXPORT_SYMBOL(kset_unregister); +EXPORT_SYMBOL(kset_find_obj); -- 2.4.3

2 2