Re: My effort to learn Linux kernel development
Hi All, Because the Linux kernel uses GCC extensions, this resource is important for a Linux kernel learner. https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.pdf Regards, Amit Kumar On Wed, Aug 11, 2021 at 5:07 PM Amit Kumar wrote: > > On Wed, Aug 11, 2021 at 3:11 PM sri vathsa wrote: > > > > Hi Amit, > > > > On Wed, Aug 11, 2021, 3:03 PM Amit Kumar wrote: > >> > >> > >> I have got a resource which is about 5.4 LTS kernel. > > > > > > Can u share that resource here, even I trying to > > Understand latest kernel. > > > Linux Kernel Programming on perlego.com > > Regards, > Amit Kumar > > Thanks, > > Dara Srivathsa > > > >> ___ > >> Kernelnewbies mailing list > >> Kernelnewbies@kernelnewbies.org > >> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB-Audio: Device or resource busy (strace log)
can you paste output of arecord -l (list of capture devices). Which device you are using and os. Does this instance is already open by default? like any video playing or something like that? Yes you can stop pulse audio and try.. On Wed, Aug 11, 2021 at 6:17 PM Jaroslav Kysela wrote: > On 11. 08. 21 14:36, Muni Sekhar wrote: > > Hi All, > > > > $ cat /proc/asound/cards > > 0 [USB]: USB-Audio - Plantronics .Audio 628 USB > > Plantronics Plantronics .Audio 628 USB at > > usb-:00:14.0-2, full speed > > > > I am using a Plantronics USB Audio headset. > > > > $ arecord --device hw:0,0 --channels 2 --format S16_LE --rate 44100Hz > x.wav > > arecord: main:722: audio open error: Device or resource busy > > > > > > 'arecord' command always fails the first time after system boot in my > > system. But subsequent execution of the 'arecord' command runs fine. > > > > > > I've attached the strace log for the "audio open error: Device or > > resource busy" failure. Is there any fix available for this issue? > > You may check which other task blocks the PCM device: > > lsof /dev/snd/pcmC0D0c > > I guess that it will be pulseaudio (device enumeration). > > Jaroslav > > -- > Jaroslav Kysela > Linux Sound Maintainer; ALSA Project; Red Hat, Inc. > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB-Audio: Device or resource busy (strace log)
can you paste output of arecord -l (list of capture devices). Which device you are using and os. Does this instance is already open by default? like any video playing or something like that? On Wed, Aug 11, 2021 at 6:06 PM Muni Sekhar wrote: > Hi All, > > $ cat /proc/asound/cards > 0 [USB]: USB-Audio - Plantronics .Audio 628 USB > Plantronics Plantronics .Audio 628 USB at > usb-:00:14.0-2, full speed > > I am using a Plantronics USB Audio headset. > > $ arecord --device hw:0,0 --channels 2 --format S16_LE --rate 44100Hz x.wav > arecord: main:722: audio open error: Device or resource busy > > > 'arecord' command always fails the first time after system boot in my > system. But subsequent execution of the 'arecord' command runs fine. > > > I've attached the strace log for the "audio open error: Device or > resource busy" failure. Is there any fix available for this issue? > > -- > Thanks, > Sekhar > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [RFC PATCH v2 05/10] block: Add block device sysfs attribute to set/clear/show LED
ÔÚ 2021/8/9 ÉÏÎç11:32, Ian Pilcher дµÀ:
> Add show & store functions in blk-ledtrig.c (attributes defined in genhd.c)
>
> Show function shows all available LEDs (LEDs associated with blkdev trigger);
> currently associated LED is shown in square brackets ([])
>
> Store function accepts either all whitespace or "none" to clear LED
>
> Signed-off-by: Ian Pilcher
> ---
> block/blk-ledtrig.c | 109
> block/blk-ledtrig.h | 8
> block/genhd.c | 8
> 3 files changed, 125 insertions(+)
>
> diff --git a/block/blk-ledtrig.c b/block/blk-ledtrig.c
> index 280fa9edc2dd..1af94dc7ea51 100644
> --- a/block/blk-ledtrig.c
> +++ b/block/blk-ledtrig.c
> @@ -6,6 +6,7 @@
>* Copyright 2021 Ian Pilcher
>*/
>
> +#include
> #include
> #include
> #include
> @@ -139,3 +140,111 @@ static int blk_ledtrig_dev_set(struct gendisk *const
> disk,
> led_set_exit_return:
> return ret;
> }
> +
> +
> +/*
> + *
> + * sysfs attribute store function to set or clear device LED
> + *
> + */
> +
> +// Returns a pointer to the first non-whitespace character in s (or a pointer
> +// to the terminating null).
> +static const char *blk_ledtrig_skip_whitespace(const char *s)
> +{
> + while (*s != 0 && isspace(*s))
> + ++s;
> +
> + return s;
> +}
> +
> +// Returns a pointer to the first whitespace character in s (or a pointer to
> +// the terminating null), which is effectively a pointer to the position
> *after*
> +// the last character in the non-whitespace token at the beginning of s. (s
> is
> +// expected to be the result of a previous call to
> blk_ledtrig_skip_whitespace.)
These are not linux kernel style comments.
> +static const char *blk_ledtrig_find_whitespace(const char *s)
> +{
> + while (*s != 0 && !isspace(*s))
> + ++s;
> +
> + return s;
> +}
> +
> +static bool blk_ledtrig_name_is_none(const char *const name, const size_t
> len)
> +{
> + static const char none[4] = "none"; // no terminating null
> +
> + return len == sizeof(none) && memcmp(name, none, sizeof(none)) == 0;
> +}
> +
> +ssize_t blk_ledtrig_dev_led_store(struct device *const dev,
> + struct device_attribute *const attr,
> + const char *const buf, const size_t count)
> +{
> + struct gendisk *const disk = dev_to_disk(dev);
> + const char *const led_name = blk_ledtrig_skip_whitespace(buf);
> + const char *const endp = blk_ledtrig_find_whitespace(led_name);
> + const ptrdiff_t name_len = endp - led_name; // always >= 0
> + int ret;
> +
> + if (name_len == 0 || blk_ledtrig_name_is_none(led_name, name_len)) {
> + blk_ledtrig_dev_clear(disk);
> + ret = 0;
> + } else {
> + ret = blk_ledtrig_dev_set(disk, led_name, name_len);
> + }
> +
> + if (ret < 0)
> + return ret;
> +
> + return count;
> +}
> +
> +
> +/*
> + *
> + * sysfs attribute show function for device LED
> + *
> + */
> +
> +ssize_t blk_ledtrig_dev_led_show(struct device *const dev,
> + struct device_attribute *const attr,
> + char *const buf)
> +{
> + struct gendisk *const disk = dev_to_disk(dev);
> + struct blk_ledtrig_led *bd_led, *disk_led;
> + int ret, c = 0;
> +
> + ret = mutex_lock_interruptible(_ledtrig_mutex);
> + if (ret != 0)
> + goto led_show_exit_return;
> +
> + disk_led = rcu_dereference_protected(disk->led,
> + lockdep_is_held(_ledtrig_mutex));
> +
> + if (disk_led == NULL)
> + c += sprintf(buf, "[none]");
> + else
> + c += sprintf(buf, "none");
> +
> + list_for_each_entry(bd_led, _ledtrig_leds, leds_list_node) {
> +
> + ret = snprintf(buf + c, PAGE_SIZE - c - 1,
> +bd_led == disk_led ? " [%s]" : " %s",
> +bd_led->led->name);
> + if (ret >= PAGE_SIZE - c - 1) {
> + ret = -EOVERFLOW;
> + goto led_show_exit_unlock;
> + }
> +
> + c += ret;
> + }
> +
> + buf[c] = '\n';
> + ret = c + 1;
> +
> +led_show_exit_unlock:
> + mutex_unlock(_ledtrig_mutex);
> +led_show_exit_return:
> + return ret;
> +}
> diff --git a/block/blk-ledtrig.h b/block/blk-ledtrig.h
> index 66a1302a4174..771000d43647 100644
> --- a/block/blk-ledtrig.h
> +++ b/block/blk-ledtrig.h
> @@ -18,6 +18,14 @@ static inline void blk_ledtrig_disk_init(struct gendisk
> *const disk)
>
> void blk_ledtrig_dev_clear(struct gendisk *const disk);
>
> +ssize_t blk_ledtrig_dev_led_store(struct device *const dev,
> + struct device_attribute *const attr,
> + const char *const buf, const size_t count);
> +
> +ssize_t blk_ledtrig_dev_led_show(struct device *const
Re: [RFC PATCH v2 00/10] Add configurable block device LED triggers
On Monday 09 August 2021 20:56:33 Marek Behún wrote: > Hello Ian, > > thank you for your proposal. Some comments below: > > On Sun, 8 Aug 2021 22:32:07 -0500 > Ian Pilcher wrote: > > > One thing that has not changed is that associations between block > > devices and LEDs are still set via an attribute on the device, rather > > than the LED. This is much simpler, as the device attribute only has > > to handle a single value (the name of the associated LED), rather than > > potentially handling multiple device names. > > It may be simpler, but it is in contrast to how the netdev trigger > works, which already is in upstream for many years. I really think we > should try to have similar sysfs ABIs here. (I understand that the > netdev trigger is currently unable to handle multiple network > interfaces - but it is possible to extend it so.) > > > I have modeled the interface for the /sys/block//led > > attribute on the sysfs interface used for selecting a trigger. All > > available LEDs (all LEDs associated with the blkdev trigger) are > > shown when the attribute is read, with the currently selected LED > > enclosed in square brackets ([]). > > I think it is reasonable to be able to set something like this: > led0 : blink on activity on any of [sda, sdb, sdc] > led1 : blink on activity on sda > led2 : blink on activity on sdb > led3 : blink on activity on sdc > > If I am reading your code correctly, it looks that only one LED can be > configured for a block device. Is this true? If so, then the above > configuration cannot be set. > > Also you are blinking the LED on any request to the block device. I > would rather expect to be able to set the LED to blink on read and on > write. (And possibly on other functions, like discard, or critical > temperature, or error, ...) I would like to know what other people > think about this. Hello! HP EliteBook laptops had dedicated LED for some kind of error and encryption indication. And there is kernel acpi/wmi driver which can control this LED. I do not know if recent HP laptops still have these LEDs, but I would suggest to design API in a way that would allow to use these dedicated LEDs for their original "vendor" purpose. I'm mentioning it just because this functionality and design is already on existing production mainstream laptops, and not something imaginary. If Linux distributions are still cooperating with laptop vendors and doing "official" Linux preloads then they may be interested in having "native" LED functionality support in kernel. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: LDD 3rd ed. - It was: Re: read() via USB bus
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: LDD 3rd ed. - It was: Re: read() via USB bus
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. > Do you mind to elaborate a bit more on this subject, please? I mean: can you > point out which chapters, which content, should be skipped (if there's really > something which is no more correct/relevant to today's practice of drivers > development and kernel hacking? I am not going to create a study guide like this, sorry, I've already given away the book for free to you :) > One more question, please... if after carefully studying its content, someone > wanted to change and update part of the book content to reflect the changes > in > Linux API and in the current best practices, would it be (legally) allowed to > publish a v4 on GitHub for the convenience of everyone interested in learning > for free? However, I understand that it would be not so easy to come up with > a > good and error free text if not addressed as a public long term project and > I'm also not sure of what tools are needed to edit PDF files. (At the moment > my question is for a hypothetical scenario, just to know whether or not it > would be technically and legally doable). Please see the license of the book for what you are, and are not, allowed to do with it to answer this question. thanks, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: LDD 3rd ed. - It was: Re: read() via USB bus
On Thu, 12 Aug 2021 11:45:45 +0200, "Fabio M. De Francesco" said: > 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. The APIs have all changed a lot since the 3rd edition. The concepts haven't changed that much. And given that the in-kernel APIs have *always* been a moving target, being able to deal with the fact that a given function now takes a 'struct foo*' rather than a 'struct bar *' is a very necessary skill for anybody who's planning to do serious kernel work. pgpIU0SPhl3tZ.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A question about staging driver like pi433
On Tue, Aug 10, 2021 at 08:12:46AM +0200, Greg KH wrote: > On Mon, Aug 09, 2021 at 11:27:13PM +, Sidong Yang wrote: > > On Mon, Aug 09, 2021 at 08:20:03PM +0200, Greg KH wrote: > > > On Mon, Aug 09, 2021 at 04:13:28PM +, Sidong Yang wrote: > > > > Hi all, > > > > > > > > I have a question about staging driver. I'm a newbie kernel developer > > > > and I tried contributed some patches for staging drivers. In those > > > > staging drivers, I'm interested in pi433 and wrote some patches for it > > > > about 2 years ago. and then I tried to go deeper for that. I tried to > > > > buy pi433 device but I can't. It seems that no longer available. > > > > > > > > In this case, pi433 should be removed from source tree? > > > > > > Why would it be removed if people still use it? > > > > Yeah, I thought there is no user using this device. I realized that it > > was bad idea. > > Is there no one using this? That's kind of hard to determine, and is > a problem we have at times :( I contacted the hardware developer in personal. And He replied positive. I would get the pi433 device soon. It would be nice that It can be tested in practice. Thanks, Sidong > > thanks, > > greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
