Re: ssh session with qemu-arm using busybox
Στις 2019-03-11 16:34, Pintu Agarwal έγραψε: Hi, I have a qemu-arm setup with busybox which I normally use to test my kernel changes. I use this command to boot it: QEMU-ARM$ qemu-system-arm -M vexpress-a9 -m 1024M -kernel ../KERNEL/linux/arch/arm/boot/zImage -dtb ../KERNEL/linux/arch/arm/boot/dts/vexpress-v2p-ca9.dtb -initrd rootfs.img.gz -append "console=ttyAMA0 root=/dev/ram rdinit=/sbin/init ip=dhcp" -nographic -smp 4 This includes, my own custom kernel and rootfs build. For rootfs I use busybox and create cpio image and use it as initrd. But, every time, if I have to copy some files inside qemu, I need to create create roofs image. This is painful. So, now I am exploring how to transfer files from my ubuntu pc to qemu-session using "ssh". I know this is possible, but I am still not successful, and bit lazy to explore these. I am sure, many of you people would have explored already "how to use ssh over qemu" and found a easy method. So, if anybody have easy setup please share with me. I could see that after adding "ip=dhcp" I get the eth0 interface like this: / # ifconfig eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1180 (1.1 KiB) TX bytes:1180 (1.1 KiB) Interrupt:22 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) But I could not ping it from ubuntu PC. Regards, Pintu ___ linux-riscv mailing list linux-ri...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv You may use the hostfw argument on qemu, e.g... -netdev user,id=unet,hostfwd=tcp::-:22 \ -net user \ and you 'll get guest's port 22 to be forwarded to hosts port , so you can do ssh root@localhost: from the host. Regards, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Meltdown/spectre patches.
Hi all, Rather than bother the main kernel list with what is going on, does anybody know if the latest source code on kernel.org contains the patches, or do I need to apply externally? Thanks, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Btrfs Questions for Personal Data Archive
Greetings All, I am assuming this is coming from me it's just going to get no reply. However if someone who works on btrfs is willing to reply to this I have a few questions. Firstly I have a lot of personal storage for archiving various things probably around ~37TB filled currently in external drives and estimate the archive to grow to around ~300 to 400 TB. All of these numbers are unformatted for people's information. I have been using btrfs but need to ask a few questions for how to create a central archive best: 1.Does the compression algorithms used as according to my knowledge they don't do it well enough to enable it for non text files? What are the performance disadvantages from a IO perspective(I can Google this but I want numbers from someone who works in a data center)? This is primary due to the central archive needing to be used for many different systems at a time. I assume around 3-4 on average maybe more including during a rebuild. Some of it is also hit bit rate encodes I have done for bluray which are around 10-22mbps per second and may need to be watched during a raid rebuild. GPU processing will be client side so don't worry about that. 2. Same as above but for software raid versus hardware raid in btrfs.I am stressing rebuild time here on a raid 5/6. Probably going to use raid 60 as that gives me a mirror plus two drives failure for redundancy. 3. I have found very little information on this but does the metadata being on a SSD actually help with performance? Very little information exist off the wiki for this. I literally goggled for a few hours and found very little even in terms of papers. Further more the archive is going to be on external hard drives for a while, as hard drives are not big enough. If people want more information or have advice on how to scale this out that would be very helpful. Generally I am looking for information related to btrfs. If anyone replies huge thanks, Nick P.S. If anyone tells me to send my questions to the btrfs list I did some stupid things and was banned from vger so I am just sending it here for now. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Confused about rtnl routing mutex scalability
Greetings All, I am curious as it after reading the network code for a while it seems that to me at least the rtnl mutex lock is a bottleneck. Is there any reason that we are still using a global mutex for all routing changes in the networking stack for the Linux kernel or does it actually scale only, seems to me that it is causing nothing but problems with deadlocks related to it or issues with locking timeouts on separate netdev routing tables for two different networks. Is this just me or does this lock actually cause serious issues or can do so. Regards, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: dumping large buffers to file
On Tue, Nov 24, 2015 at 1:30 AM, Ramon Fried wrote: > Hi. > > I'm currently debugging a ISP DMA issue in a kernel module. > > For debugging, I would like to dump buffers to a file on run time. > > The buffers are quite big, 1MB at least. > > As saving a file directly from kernel is discouraged, is there any available > framework for doing such a thing ? > > I can think of numerous ways of transferring the buffer to user space and > saving it by a dedicated user process (Netlink, sysfs, char device, etc.) > > > I just don't want to invent the wheel. How do you do it ? > > > > Thanks. > > Ramon > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > If you can use printk just switch the log level to a log level that prints to the syslog buffer for kernel messages. If you have enough space on your partition for root this shouldn't be a problem, however if it is them I would recommend sysfs or procfs exporting as there better suited for debugging as the others are for user space applications needing access to kernel resources indirectly or device driver user space interaction. Hope this Helps, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Formal Apology
Greetings All, I am formally apologizing for last year. After reading back other it all I can state is wow no wonder I was banned, not only did I not listen but all my patches were not tested. All I can state is I am so sorry and really feel stupid about so much that I feel like hitting my head against the wall a few times. In addition I cannot even believe I was that stupid and arrogant. To be honest I am surprised I wasn't banned a few weeks earlier :. Sorry, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: bug kernel v4.0.1
On 2015-05-04 12:37 PM, Albino Biasutti Neto wrote: > Hi > > I compiled kernel v4.0.1 of git linux-stable is with bug. > > Kernel panic dont start boot loading. Back 3.16. > > > Albino > > Albino, Since this is a kernel panic it would be nice if you can send us a back trace of the function calls on your screen when the panic happens. Otherwise this is impossible for us to trace your kernel panic related to boot loading. Nick ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: running queue processes
On 2015-05-04 04:45 AM, Robert P. J. Day wrote: > On Sun, 3 May 2015, Nicholas Krause wrote: > >> >> >> On May 3, 2015 9:16:27 AM EDT, Ruben Safir 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 > Rday, Yet everything I ask a question I get a similar response like do your homework or read more rather then any help. Clearly I understand with my older questions why but all of my questions now are similar in nature to this so there is no reason for that. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: 4.1-rc1 fails with O3 optimization
On 2015-04-28 03:44 PM, Andev wrote: > On Tue, Apr 28, 2015 at 2:30 PM, leo kirotawa wrote: >> Yep, I can try. Do you know when this issue start ? >> > > I remember 4.0 working fine. You can try and use that as starting point. > Just a question as I have been reading this for a while,is this only for x86 or other architectures too as I would advise to bisect/test his patch on ARM and other CPU platforms too. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Reusable Memory Manager
On 2015-04-22 10:47 PM, Kenneth Adam Miller wrote: > On Wed, Apr 22, 2015 at 10:42 PM, nick wrote: > >> >> >> On 2015-04-22 10:39 PM, Kenneth Adam Miller wrote: >>> So, I have a particular use case that has a lot to do with security. >>> >>> Basically, we have a intended secure kernel version with grsecurity and >>> other patches on it, and we have a specific application that has to do >> data >>> filtering as an inline reference monitor. >>> >>> The problem is, there is throughput and design considerations that are >>> limiting efficiency in the sense that it is highly difficult to make the >>> system concurrent and also highly difficult to scale-all while also being >>> secure. >>> >>> Basically, the memory regions have to be encoded at compile time because >> of >>> the way kernel segregation works. This makes the security proof of the >>> system far more simple and manageable; it's easy to say that no userland >>> monitor which is being given access to a specific memory region can >> access >>> outside of the region to which it is allocated, because it's statically >>> set. The tradeoff here is pretty severe, because the static settings that >>> have to be adopted pretty much mean that each particular monitor is >> given a >>> specific memory region; if there's a lot of traffic to a specific monitor >>> type, then that one type will be overwhelmed, but not even at the rate >> that >>> the machine itself could support. This is because all the other cores are >>> potentially sitting unused while the one in this worst case scenario is >>> running out of memory and not able to dispatch work to more cores. >>> >>> So my ultimate question is: is there some reusable, dynamic memory >>> allocation manager that can be used? I'm thinking that there has to, at >> the >>> least, be the constructs by which user land processes are managed and >>> divvied memory by the kernel itself. Does anybody know where that source >>> would be? Where I can go in order to learn more about that? >>> >>> What we want is a secure way to dynamically allocate memory from these >>> static memory page boundaries such that >>> >>> >>> >>> ___ >>> Kernelnewbies mailing list >>> Kernelnewbies@kernelnewbies.org >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> >> You didn't finish your email such that ... . I would be glad to try and >> help if you finish off what your requirements are. >> Nick >> > > > Ooops, sorry, I didn't know that last fragment was there. I think the > previous part explains what I am looking for. > That's OK. You may want to look into virtual memory management of the kernel. However, I doubt that's what you want the issue is some that reallocates and takes advantage of CPU and already allowed kernel date structures. If that is the case look into writing a slab allocator for your security features you have added to the kernel. Further more writing a slab allocator is non trivial and you will need to look into the way memory is being handled in terms of hardware caches to find the best options with the slab functions in the kernel to get the best performable slab for your needs.This is link to a chapter in a book explaining this,https://www.kernel.org/doc/gorman/html/understand/understand011.htm. The only issue is the book is outdated in terms of kernel releases but the concepts are similar if not identical to the current releases. Hope this Helps, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Reusable Memory Manager
On 2015-04-22 10:39 PM, Kenneth Adam Miller wrote: > So, I have a particular use case that has a lot to do with security. > > Basically, we have a intended secure kernel version with grsecurity and > other patches on it, and we have a specific application that has to do data > filtering as an inline reference monitor. > > The problem is, there is throughput and design considerations that are > limiting efficiency in the sense that it is highly difficult to make the > system concurrent and also highly difficult to scale-all while also being > secure. > > Basically, the memory regions have to be encoded at compile time because of > the way kernel segregation works. This makes the security proof of the > system far more simple and manageable; it's easy to say that no userland > monitor which is being given access to a specific memory region can access > outside of the region to which it is allocated, because it's statically > set. The tradeoff here is pretty severe, because the static settings that > have to be adopted pretty much mean that each particular monitor is given a > specific memory region; if there's a lot of traffic to a specific monitor > type, then that one type will be overwhelmed, but not even at the rate that > the machine itself could support. This is because all the other cores are > potentially sitting unused while the one in this worst case scenario is > running out of memory and not able to dispatch work to more cores. > > So my ultimate question is: is there some reusable, dynamic memory > allocation manager that can be used? I'm thinking that there has to, at the > least, be the constructs by which user land processes are managed and > divvied memory by the kernel itself. Does anybody know where that source > would be? Where I can go in order to learn more about that? > > What we want is a secure way to dynamically allocate memory from these > static memory page boundaries such that > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > You didn't finish your email such that ... . I would be glad to try and help if you finish off what your requirements are. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Question about porting over magic lantern kernel hardware support to mainline
Greetings All, I was wondering about reading this forum page,http://www.magiclantern.fm/forum/index.php?topic=14847.0;prev_next=next#new if porting over magic lantern's change to the main line kernel is a good idea or does it need to be kept separate.Honestly, from my personal experience high resolution cameras running Linux may be of great use to thousands of independent film makers worldwide and it would be easier for vendors of said cameras to use the main line kernel for this and not a patched vendor kernel for supporting there hardware. If the camera vendors are very closed mine, then I would see no point in doing this. Anyhow please let me known of any options on main lining this or keeping it separate. Thanks, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How do _you_ read the linux source?
On 2015-04-20 01:45 AM, Christoffer Holmstedt wrote: > 2015-04-20 5:11 GMT+02:00 nick : >> There were a few things I did when starting to learn the kernel >> 1. Read Robert Love's Linux Kernel Development, I don't care how much you >> think >> you known about the kernel read and trace the actual kernel code with this >> book!! >> 2.Read a book on device drivers and the Linux networking stack, I >> read Linux networking internals for this > > Thank you Nick, I'm just getting started with linux kernel development > and have been looking around for books both more general and specific > to networking. One thing in common several books I've found have is > that they are based on the 2.6 version of the kernel (or older). Some > parts have changed but are entire chapters in the above mentioned > books too old to make sense when working on version linux kernel 4.1 > and beyond? > What you need to do is look at the source code and see what has changed this writing of the book. This is what I do when reading kernel programming books or documentation. Further more around way is to read the logs of the networking mailing lists for the kernel to see what has changed recently. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How do _you_ read the linux source?
This is not user space where bugs are much easier to trace,basically understand your system calls,threading theory,how to use gdb and memory analysis toolkit,maybe tool chain issues if working with embedded systems. The kernel is very complex in debugging everything from deadlock to registers being written from being wrong on exact hardware can happen. Further more due to the kernel being only a layer above hardware we very easily get bugs that can only be reduplicated on exact hardware.(working on this too) 8. This a add on to 7,learn assembly for tracing bugs as this is very helpful for reading register trace backs of oops/kernel panics if necessary for debugging.(another thing on my kernel learning list) Hope this Helps, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Question about assembly in set bit function for x86 architecture
Greetings All,
I am wondering what the below code in the asm modifier does:
static inline void set_bit(int nr, void *addr)
{
asm("btsl %1,%0" : "+m" (*(u32 *)addr) : "Ir" (nr));
}
This would be very helpful as I am new to x86 assembly and don't
even known what register(s)/instruction(s) this touches and therefore this
is impossible for me to look up in the Intel Manuals. If someone either
tells me the registers/instructions this uses or explains the code that
would be very helpful.
Nick
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: qemu problem
On 2015-04-18 10:14 PM, Mustafa Hussain wrote: > Hi, > i'm trying to run kernel with qemu but i get some errors while running this > command > " > qemu-system-x86_64 --nographic -M pc -no-reboot -net nic,model=e1000 > -net nic,vlan=0 -net user,hostfwd=tcp:1:10.0.2.15:22-hda hd.img > -append "root=/dev/hda1 debug rw console=ttyS0,115200" -s -kernel > " > error says that > qemu-system-x86_64: -net user,hostfwd=tcp:1:10.0.2.15:22: invalid host > forwarding rule 'tcp:1:10.0.2.15:22' > > qemu-system-x86_64: -net user,hostfwd=tcp:1:10.0.2.15:22: Device 'user' > could not be initialized > > any help ? This looks like a tcp forward rule being wrong for qemu in its configuration files. If you can send the config files for your configured qemu I may be able to help. Nick > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: xtime variable in kernel 4.0
On Tue, Apr 14, 2015 at 9:20 AM, Greg KH wrote: > On Tue, Apr 14, 2015 at 08:47:08AM -0400, Mohammad A Khasawneh wrote: >> Hi everyone, >> >> I'm trying to develop a syscall in kernel v4.0 which copies the xtime >> variable >> to user space. I can find the variable in 3.X but it seems to have been >> changed >> in 4.0. Can anyone point me to its location? > > git is your friend, it shouldn't be hard to find where it went to, just > look at all commits that changed between the version you find it, and > the new one, and run 'git log path/filename.c' > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies I am wondering why you need to return the wall clock time to user space. This seems unnecessary to me unless you can find some applications that need the wall clock time in order to function correctly. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel thread scheduling
On April 12, 2015 1:06:57 AM EDT, Ruben Safir wrote: >On 04/12/2015 12:36 AM, Mohammed Ghriga wrote: >> In addition to the suggestions that were offered, I recommend you try >reading Chapter 16: >https://www.google.com/search?tbo=p&tbm=bks&q=isbn:0596554672 (pages: >267-272). >> > >http://it-ebooks.info/book/481/ > >FWIW I found this lovely wait example in the other kernel text under >the >scheduling section > >Sleeping and Waking Up page 58 in Robert Love, Linux Kernel Development > >http://www.it-ebooks.info/book/819/ > I recommended this book as that was how I learn the basics of kernel development. Again if your interested in certain areas I will be glad to link/explain it to you to the best of my knowledge. Nick >Kernelnewbies mailing list >Kernelnewbies@kernelnewbies.org >http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel thread scheduling
On 2015-04-11 11:02 PM, Ruben Safir wrote:
> On 04/11/2015 10:21 PM, Ruben Safir wrote:
>> On 04/10/2015 09:09 AM, nick wrote:
>>>
>>>
>>> On 2015-04-09 11:37 PM, Ruben Safir wrote:
>>>> On 04/09/2015 10:52 PM, nick wrote:
>>>>> Before asking questions again like this please look into either using lxr
>>>>> or ctags
>>>>> to navigate the kernel tree for answers as can be faster then waiting for
>>>>> me or
>>>>> someone else to respond.
>>>>
>>>>
>>>> well, I reading the text is ctags aren't much value there.
>>>>
>>> Ctags is useful for searching the code, which is why I am recommending it.
>>> Nick
>>
>> I have it built into gvim, but you can't use it from a textbook. I'm
>> finding it is not as useful as it could be for the kernel code. There
>> are stacks of tags to get around. Another 2 days to learn to get around
>> tags in vi is not in the agenda right now. It is the tool I have so
>> I'll have to live with it right now.
>>
>> I also have a question that is not obvious from the code I'm looking at.
>> I'm not sure how these structs are attached together. Or more
>> specifically, I'm not sure how pulling the correct sched_entity gets one
>> the coresponding task_entity
>>
>> You have
>> struct task_struct with a
>> struct sched_entity
>>
>> struct sched_enitities are nodes in the RB tree
>> which are a "container" for "struct rb_node run_node".
>>
>> So a look at sched_entity ... is in ../linux/sched.h
>>
>> 1161 struct sched_entity {
>> 1162struct load_weight load;/* for load-balancing */
>> 1163struct rb_noderun_node;
>> 1164struct list_head group_node;
>> 1165unsigned int on_rq;
>> 1166
>> 1167u64 exec_start;
>> 1168u64 sum_exec_runtime;
>> 1169u64 vruntime;
>> 1170u64 prev_sum_exec_runtime;
>> 1171
>> 1172u64 nr_migrations;
>> 1173
>> 1174 #ifdef CONFIG_SCHEDSTATS
>> 1175struct sched_statistics statistics;
>> 1176 #endif
>> 1177
>> 1178 #ifdef CONFIG_FAIR_GROUP_SCHED
>> 1179int depth;
>> 1180struct sched_entity *parent;
>> 1181/* rq on which this entity is (to be) queued: */
>> 1182struct cfs_rq *cfs_rq;
>> 1183/* rq "owned" by this entity/group: */
>> 1184struct cfs_rq *my_q;
>> 1185 #endif
>> 1186
>> 1187 #ifdef CONFIG_SMP
>> 1188/* Per-entity load-tracking */
>> 1189struct sched_avg avg;
>> 1190 #endif
>> 1191 };
>>
>> I see no means of referencing a specific task from this struct that
>> forms the node. So when you pull the node with the smallest vruntime
>> from the left most postion of the RB tree, by calling pick_next_task(),
>>
>>
>> static struct sched_entity *__pick_next_entity(struct sched_entity *se)
>> {
>> struct rb_node *next = rb_next(&se->run_node);
This finds the next node in the red black tree for sched_enities.
Basically rb_next finds the next node in the tree. The argument is
the rb_node structure embedded in the structure using a red black
tree.
>>
>> if (!next)
>> return NULL;
>>
If there is no runnable task return NULL and pick_next_task will run the
idle_task for this cpu.
>> return rb_entry(next, struct sched_entity, run_node);
>> }
>>
>>
>> how do we know what task we are attached to?
>>
Also try to read Chapter 6 of Linux Kernel Development as if have read that
chapter understanding how red black trees and other data structures work in
kernel code would make more sense.
Nick
>> Ruben
>>
>>
>
> I'm still loss on how we know which taks_struct is being used but as a
> side note, I found this also very puzzling
>
> return rb_entry(next, struct sched_entity, run_node);
> With help I ran it down to this:
>
> http://lxr.free-electrons.com/source/include/linux/rbtree.h#L50
>
> #define rb_entry(ptr, type, member) container_of(ptr, type, member)
>
> which leads me to yet another macro
>
> 798 #define container_of(ptr, type, member) ({ \
> 799 const typeof( ((type *)0)->member ) *__mptr = (ptr);\
> 800 (type *)( (char *)__mptr - offsetof(type,member) );})
>
>
> This is a use of macros I'd never seen before up close. If anyone could
> help me understand it, I'd appreciate it.
>
> Ruben
>>
>>
>>>> ___
>>>> Kernelnewbies mailing list
>>>> Kernelnewbies@kernelnewbies.org
>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>>
>>>
>>>
>>
>>
>> ___
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
VFS/driver core overhead
Greetings All, After reading through the code for the usb and vfs core infrastructure, I was wondering if after reading it if I am correct in my notion of there being very little overhead or none at all int these areas of the kernel. This is due to be noticing most drivers and file systems wrap around the core/vfs and therefore the overhead is very little and no need to worry about it like the overhead of the kernel's process structures based off task_struct .Honestly, I could benchmark this area of the kernel but it's hard to remove the file system/drivers interfering with my benchmarks due to me not knowing of any one way to do that. If someone either points me to a benchmark for me to test this or answers it that would be very helpful. Thanks, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel thread scheduling
On 2015-03-22 08:05 PM, Ruben Safir wrote: > On 03/22/2015 07:30 PM, nick wrote: >> I would recommend reading Chapters 3 and 4 of Linux Kernel Development by >> Robert Love >> as when I was learning the scheduler and process management > > > how much has the scheduler changed since then. It was completely > overhauled when the CFS was created > > > The 3rd edition of this book was written after CFS was in the kernel so the chapters are pretty up to date. Nick > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel thread scheduling
On 2015-03-22 07:14 PM, Vincenzo Scotti wrote: > Thank you for the example. > > I understand what are the scheduling mechanics depending on task->state. > But suppose another situation. > Let's say I change current state to TASK_INTERRUPTIBLE. If I start now some > long > operation, then shouldn't the scheduler kick in as soon as he can and put my > thread > asleep? Or should I call necessarily schedule()? And if so, why? > > > Greetings Vincenzo. I would recommend reading Chapters 3 and 4 of Linux Kernel Development by Robert Love as when I was learning the scheduler and process management for the kernel,I found these chapters to be very useful.Further more for user space you are correct to my knowledge schedule is called for internal tasks that are taking too long in kernel land or to reschedule to another task,not for user space based tasks are TASK_INTERRUPTIBLE works fine there. Hope this Helps, Nick ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Get Back Into Kernel Work
On 2015-03-15 12:46 PM, Ruben Safir wrote: > On Sun, Mar 15, 2015 at 04:39:31PM +, Hugo Mills wrote: >> On Sun, Mar 15, 2015 at 12:24:12PM -0400, Ruben Safir wrote: >>> On Sun, Mar 15, 2015 at 05:16:27PM +0100, Levente Kurusa wrote: >>>> On Sun, Mar 15, 2015 at 12:01:27PM -0400, Nicholas Krause wrote: >>>>>>> [...] >>>>> I was interested in Socs in staging as I believe there are a few >>>>> would someone like to point me to one that I can get hardware for. > > Your 100% correct. I apologize > > Ruben > > >>>> >>>> Please read my message again. It should be YOU who does the research >>>> about the work that YOU want to do, not us... >>> >>> >>> I didn't write this. Are you intentionally trolling this? >> >>Nobody's claiming you did. This is a different thread to yours, >> with a different subject line. Note that none of the quoted messages >> above had your name as attribution. >> >>> The initial message under this subject had nothing to do with this. >>> BTW - the atitiude is piss poor for what is SUPPOSED to be newbies area. >>> Try taking some trips from Ernie and Fewer from Bert. >> >>This particular newbie (nick) has a reasonably long and ignoble >> history in the kernel development area. He used up quite a lot of the >> available polite late last summer, and isn't at the moment giving any >> indications that he's made any improvements. >> >>> PS - no need to CC me when I'm reading the list. >> >>It's the default position on these mailing lists. You're generally >> not going to have anyone remember that you don't want to be CC'd. A >> message in your .sig to that effect might help, but it probably won't. >> >>Hugo. >> >> -- >> Hugo Mills | Be pure. >> hugo@... carfax.org.uk | Be vigilant. >> http://carfax.org.uk/ | Behave. >> PGP: 65E74AC0 | Torquemada, >> Nemesis > > > >> Look I really do want to try and improve my rep as I really enjoy learning and programming the kernel. I don't want to come up as I known everything I don't,all I am is some honest criticism of where I am going wrong. Nick ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Get Back Into Kernel Work
Greetings All, After my terrible results before and getting banned from the list due to these results, I am wondering if there is any work in the USB or Networking Subsystem I can start with. Further more recently I read Essential Kernel Drivers so I have some idea of how to write drivers now and want to get my feet wet. In addition if I am still not trusted yet,that's OK too. :) Thanks, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel Locking Question
On 2015-03-11 09:48 PM, valdis.kletni...@vt.edu wrote: > On Wed, 11 Mar 2015 19:03:33 -0400, Nicholas Krause said: > >> was wondering of how this would improve file system scalability and >> reliability if implemented in file system code for btrfs worker threads. > > Step 1: Figure out what locks are contended in actual systems. > Step 2: Determine if the scope of a contended lock can be reduced. > Step 3: ??? > Step 4: Profit! > > Note that improving scalability will often cause reliability issues, > because as you decompose locks into sets of smaller locks, you increase > the number of ways you can get it wrong. The BKL, for all its uglyness, > was pretty hard to screw up. On the other hand, we probably would never > have gotten rid of it if somebody hadn't put lockdep into the kernel. It > was painful enough even with automated testing tools > Thanks Valdis, That makes sense to me. I was wondering however about the reader vs writer issues in file systems too as this seems to me coming up a lot in btrfs and other file systems for various reasons. Thanks Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Get local CPU id
On Mon, Mar 9, 2015 at 12:26 PM, Jeff Haran wrote: > -Original Message- > From: kernelnewbies-boun...@kernelnewbies.org > [mailto:kernelnewbies-boun...@kernelnewbies.org] On Behalf Of Matwey V. > Kornilov > Sent: Monday, March 09, 2015 8:35 AM > To: kernelnewbies@kernelnewbies.org > Subject: Re: Get local CPU id > > > Many thanks for all answers. smp_processor_id() works just fine in interrupt > context. > > Unfortunately /proc/interrupts is not what I was looking for. My idea was to > print a line to dmesg at every interrupt to have a timestamp like the > following: > > [ 926.440799] Enter intr at 0 > [ 926.441059] Exit intr at 0 > > Every interrupt? You might want to spend some time thinking about which > interrupts you don't want to do the above printing for. > > Jeff Haran > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Jeff, He can just limit the dmesg output by using console_limit I believe. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Mouse driver
On 2015-03-06 11:36 PM, Ronit Halder wrote: > This is my semester project and Thanks. > Does it have to be a input driver? If you really want to impress your teacher and get a better mark,try writing a basic network or usb driver. Nick > On Sat, Mar 7, 2015 at 10:04 AM, nick wrote: >> Ronit, >> What are your reasons for writing this driver? In addition if you have >> the kernel tree lying around look under drivers/input/mouse for mouse >> drivers that are in production to help you understand how to write >> one better. >> Good Luck, >> Nick >> >> On 2015-03-06 11:27 PM, Ronit Halder wrote: >>> Hi,I want to write mouse driver for linux ( usb mouse). I am reading >>> "Linux device driver" and "Linux kernel development". But i don't how >>> to start writing the driver. >>> So,Please help. >>> >>> Best regards, >>> Ronit. >>> >>> ___ >>> Kernelnewbies mailing list >>> Kernelnewbies@kernelnewbies.org >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Mouse driver
Ronit, What are your reasons for writing this driver? In addition if you have the kernel tree lying around look under drivers/input/mouse for mouse drivers that are in production to help you understand how to write one better. Good Luck, Nick On 2015-03-06 11:27 PM, Ronit Halder wrote: > Hi,I want to write mouse driver for linux ( usb mouse). I am reading > "Linux device driver" and "Linux kernel development". But i don't how > to start writing the driver. > So,Please help. > > Best regards, > Ronit. > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: What happens when an interrupt comes while in middle of printk?
On 2015-02-24 10:41 PM, greg.freem...@gmail.com wrote: > > > On February 24, 2015 10:07:59 PM EST, manty kuma wrote: >> Dear All, >> >> What happens if an interrupt comes while in middle of printk execution >> and >> the interrupt handler has a printk in it? >> >> There is a chance that the log_buf could be corrupted. isn't it? >> >> Best Regards, >> Manty >> >> > Manty, > > I admit to never looking, but I think you will find printk is atomic in > someway. You should review the source code to be sure. > > Also remember the kernel is smp (symmetric multi-processing), so if printks > were not atomic you would have line corruption far more frequently than just > when an interrupt hits at the wrong time. > > I've never seen corruption of that type. (Or at least not recently. I seem > to remember that issue in the 1980's, but that was the UNIX kernel.) > > Greg > Greg, You are right here as printk works anywhere needed after console is enabled in the boot of the kernel. The only issue is if you are too early in the kernel's boot cycle you need to use early_printk, to my knowledge through most architectures support this function including x86. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Port Newer Kernel to Android Device
On 2015-02-22 07:55 PM, valdis.kletni...@vt.edu wrote: > On Sun, 22 Feb 2015 13:19:40 -0500, Nicholas Krause said: >> Validis, >> That was my concern. How much forward porting is required. > > That will depend on your actual skill level. That which is a long weekend's > work for a master kernel hacker will be several week's work for a journeyman, > a summer's project for a beginner, and impossible for a neophyte. > > But I will go out on a limb and say that if you've already gotten the > patch, looked at it, and still can't make even an estimate of how long it > would > take you, you're probably not going to be able to do the porting. > Valdis, This is just a idea for now I haven't have the idea to look at making the porting patch(es) yet. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Port Newer Kernel to Android Device
Greetings Fellow Kernel Developers, I was wondering if there is any way to port a newer kernel to my device without breaking the android user space. The device is a Samsung Alpha and it would be nice to run a newer kernel for various reasons. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Use of SCHED_SOFTIRQ
Vignesh, You forgot to mention that schedule does not itself pick the next task. The actual function called is pick_next_task which uses the leftmost cached entry in the red black tree of able to run processes to run next. Nick On 2015-01-28 12:53 PM, Vignesh Radhakrishnan wrote: > Hey Sreejith, > > > softirq's are run as bottom half processing (after an interrupt is handled > or when there is no work to be done - > https://www.kernel.org/doc/htmldocs/kernel-hacking/basics-softirqs.html ) > and sched_softirq is one such soft irq whose only function is confined to > the routine run_rebalance_domain(). > > > __schedule() is the main scheduling function that tries to pick the next > task and then perform context switch and other associated scheduling > functions. Since run_rebalance_domain() need not be run at that exact time > frame, it is scheduled for later time when the cpu can take it up using > softirq's. Therefore __schedule() need not be called in this softirq > context as such because these are independent operations. > > Hope this helps. > > Thanks and regards, > Vignesh Radhakrishnan > > On Wed, Jan 28, 2015 at 10:25 PM, Sreejith M M > wrote: > >> Hi, >> >> I was reading LKD by Robert Love. I got the following idea from the book. >> >> >> Correct me if I am worng >> I was checking through source code and I found that on every timer >> interrupt, through sched/fair.c we are raising the SCHED_SOFTIRQ(). >> I was checking the relation between SCHED_SOFTIRQ and actual >> __schedule() function. >> >> My assumption: >> schedule() function is the function which selects the processes which >> are ready to run in run queue. schedule() function is called in every >> timer tick. >> >> What I was thinking is that schedule() will be called as part of >> handling SCHED_SOFTIRQ() . But in source code, SCHED_SOFTIRQ is >> handled through run_rebalance_domain() function (sched/fair.c) . I am >> unable to trace __schedule() from this function. >> >> Am I missing anything or my assumptions are wrong? >> -- >> Regards, >> Sreejith >> >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > > > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Maintainer Hasn't Picked up my patch after git resend for Ipmi subsystem
Greetings All, I am unable to get through to the maintainer of the ipmi subsystem for a patch,that I am resending. Does anyone known if they are really busy with other kernel work? Cheers Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Make cscope fails for me now as of lastest commits on Linus's tree
Valdis, You were right about my build issues. I git cloned a fresh copy of Linus's tree and it works fine now. Thanks Again, Nick On 2015-01-18 05:14 PM, valdis.kletni...@vt.edu wrote: > On Sat, 17 Jan 2015 23:28:18 -0500, nick said: >> Greetings Kernel Developers, >> After pulling the latest kernel commits for Linus’s tree, I am >> getting a build failure with make cscope. Below is the error >> messages. >> find: unknown predicate `--cc' >> I am unsure of why I am getting this and if this is a bug or an issue >> with my machine. > > Obvious first thing to do is 'make -v cscope' and see what the entire command > line that's failing is. I'm fairly sure that you've managed to mess up your > source tree or build environment somehow, because: > > [/usr/src/linux-next] find [a-z]* -type f | xargs grep -e "--cc" > scripts/get_maintainer.pl: Using "--roles" or "--rolestats" with git > send-email --cc-cmd or any > [/usr/src/linux-next] > > There's only one occurrence of "--cc" in the current source tree, and it's not > relevant as it's part of a longer string. > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Make cscope fails for me now as of lastest commits on Linus's tree
Greetings Kernel Developers, After pulling the latest kernel commits for Linus’s tree, I am getting a build failure with make cscope. Below is the error messages. find: unknown predicate `--cc' I am unsure of why I am getting this and if this is a bug or an issue with my machine. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: booting arm board
John, I would recommend building the latest kernel,if it doesn't boot please git bisect and send in a bug report with the commit to revert, if there is a obvious commit that causes issues. If you don't known the maintainer/lists to send the message to run ./scripts/get_maintainer -f on the file in question from the root directory of your cloned git tree and is should tell you who to mail the message to and cc the message to. Cheers, Nick On 2015-01-11 10:38 PM, John de la Garza wrote: > I am trying to boot a foxg20 board. It uses an at91sam9g20 chip an > used to work in linux 3.5. I am looking for some advice on how to get > mainline linux to boot on it. > > I first tried bisecting and found this commit: > 4cf3326ab5f34a333a46c59d0d3783db9cef13bf > > which is where it wouldn't boot > > I figured I should understand what broke, I ended up simply upping > MMC_CMD_RETRIES from 3 to 10. So I was able to boot the version that > caused it to not work. This change doesn't fix the lastest has unified > some of the driver code. > > My question is: > > What is a good way to boot the latest kernel? Should I see where it > breaks then keeping fixing that and moving forward or should I just > start with the latest and take it from there? > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: catch exit status of daemon
Yash, There are two ways to do this either use the signals API or IPC(inter-process communication) libraries. I don't known the functions off the top of my head but this can get you started. Nick On 2015-01-06 10:22 AM, Yash Jain wrote: > Hello All, > I have one dumb question, > I wanted to write a process which monitors the exit status of the daemon, > > The Main process would fork a service, which would internally fork a child > and , exit from the process. If main process wants to query the status of > the daemon, how it can be achived. > > For ex : > Process A would call a syslog service, which would internally fork a child, > daemon it and exit, so if process A wants to wait for the syslog process, > is it possible. > > Thanks in advance > > Regards, > Yash. > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: videobuf2_core oops, recent media_build. dvbsky t980c's
Chris, I would agree that is the best idea as of now. In addition, just curious why don't you just git bisect this as this may be easier then waiting. Nick On 2014-12-29 02:47 PM, Chris Lee wrote: > I'm running 3.19.0-rc1 > > This started on the Prof 7301 in the 3.18 kernel when vb2 was > implemented in the cx88 driver, previously vb2 wasn't used. > > I do a lot of work in the dvb side of the media kernels but have never > done any work on the vb2 side of things and don't really feel > comfortable messing around in there. I'll stick to what I know. > > Ive reported it in the V4L media mailing list, we'll see if it gets > any attention there. > > Chris Lee > > On Mon, Dec 29, 2014 at 12:11 PM, nick wrote: >> Chris, >> Please try the latest rc kernel to see if the issue is fixed. >> Regards Nick >> >> On 2014-12-29 09:47 AM, Chris Lee wrote: >>> Im seeing the same issue and others using the Prof 7301, different >>> drivers, same vb2 usage though. Its defn a vb2 issue across multiple >>> devices :( >>> >>> Chris Lee >>> >>> On Mon, Dec 29, 2014 at 7:47 AM, Chris Lee wrote: >>>> Im seeing the same issue and others using the Prof 7301, different >>>> drivers, same vb2 usage though. Its defn a vb2 issue across multiple >>>> devices :( >>>> >>>> Chris Lee >>>> >>>> On Mon, Dec 29, 2014 at 7:38 AM, Jurgen Kramer wrote: >>>>> >>>>> On Sat, 2014-12-27 at 10:35 +0100, Jurgen Kramer wrote: >>>>>> I am seeing kernel oopses using recent media_builds on kernel 3.17: >>>>>> >>>>>> [ 506.969697] BUG: unable to handle kernel NULL pointer dereference at >>>>>> 0058 >>>>>> [ 506.969720] IP: [] vb2_thread+0x17a/0x480 >>>>>> [videobuf2_core] >>>>>> [ 506.969739] PGD 0 >>>>>> [ 506.969746] Oops: 0002 [#1] SMP >>>>>> [ 506.969754] Modules linked in: nf_conntrack_netbios_ns >>>>>> nf_conntrack_broadcast cfg80211 rfkill ip6t_rpfilter ip6t_REJECT >>>>>> xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter >>>>>> ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 >>>>>> ip6table_mangle ip6table_security ip6table_raw ip6table_filter >>>>>> ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 >>>>>> nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw sp2(OE) >>>>>> si2157(OE) si2168(OE) i2c_mux nouveau cx25840(OE) cx23885(OE) >>>>>> altera_ci(OE) tda18271(OE) altera_stapl(OE) videobuf2_dvb(OE) >>>>>> videobuf2_core(OE) videobuf2_dma_sg(OE) videobuf2_memops(OE) snd_seq >>>>>> snd_seq_device snd_pcm snd_timer snd video i2c_algo_bit ttm >>>>>> drm_kms_helper soundcore iTCO_wdt ppdev gpio_ich iTCO_vendor_support >>>>>> tveeprom(OE) cx2341x(OE) >>>>>> [ 506.969871] coretemp dvb_core(OE) v4l2_common(OE) videodev(OE) >>>>>> media(OE) kvm crc32c_intel raid456 async_raid6_recov async_memcpy >>>>>> async_pq async_xor drm xor async_tx raid6_pq microcode serio_raw shpchp >>>>>> i7core_edac edac_core i2c_i801 lpc_ich mfd_core parport_pc parport >>>>>> ite_cir(OE) rc_core(OE) tpm_infineon tpm_tis tpm acpi_cpufreq nfsd >>>>>> auth_rpcgss nfs_acl lockd sunrpc mxm_wmi asix usbnet r8169 mii wmi >>>>>> [ 506.969970] CPU: 0 PID: 3160 Comm: vb2-cx23885[0] Tainted: G >>>>>> OE 3.17.4-200.fc20.x86_64 #1 >>>>>> [ 506.969982] Hardware name: To Be Filled By O.E.M. To Be Filled By >>>>>> O.E.M./P55 Extreme, BIOS P2.70 08/20/2010 >>>>>> [ 506.969993] task: 8800bc18e220 ti: 88020d36c000 task.ti: >>>>>> 88020d36c000 >>>>>> [ 506.970002] RIP: 0010:[] [] >>>>>> vb2_thread+0x17a/0x480 [videobuf2_core] >>>>>> [ 506.970021] RSP: 0018:88020d36fe68 EFLAGS: 00010246 >>>>>> [ 506.970663] RAX: RBX: RCX: >>>>>> 000b >>>>>> [ 506.971305] RDX: 0058 RSI: 8800bc18e220 RDI: >>>>>> 0058 >>>>>> [ 506.971952] RBP: 88020d36fec0 R08: 88020d36c000 R09: >>>>>> 158f >>>>>> [ 506.972611] R10: 30de R11: 0010 R12: >>&g
Re: videobuf2_core oops, recent media_build. dvbsky t980c's
Chris, Please try the latest rc kernel to see if the issue is fixed. Regards Nick On 2014-12-29 09:47 AM, Chris Lee wrote: > Im seeing the same issue and others using the Prof 7301, different > drivers, same vb2 usage though. Its defn a vb2 issue across multiple > devices :( > > Chris Lee > > On Mon, Dec 29, 2014 at 7:47 AM, Chris Lee wrote: >> Im seeing the same issue and others using the Prof 7301, different >> drivers, same vb2 usage though. Its defn a vb2 issue across multiple >> devices :( >> >> Chris Lee >> >> On Mon, Dec 29, 2014 at 7:38 AM, Jurgen Kramer wrote: >>> >>> On Sat, 2014-12-27 at 10:35 +0100, Jurgen Kramer wrote: >>>> I am seeing kernel oopses using recent media_builds on kernel 3.17: >>>> >>>> [ 506.969697] BUG: unable to handle kernel NULL pointer dereference at >>>> 0058 >>>> [ 506.969720] IP: [] vb2_thread+0x17a/0x480 >>>> [videobuf2_core] >>>> [ 506.969739] PGD 0 >>>> [ 506.969746] Oops: 0002 [#1] SMP >>>> [ 506.969754] Modules linked in: nf_conntrack_netbios_ns >>>> nf_conntrack_broadcast cfg80211 rfkill ip6t_rpfilter ip6t_REJECT >>>> xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter >>>> ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 >>>> ip6table_mangle ip6table_security ip6table_raw ip6table_filter >>>> ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 >>>> nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw sp2(OE) >>>> si2157(OE) si2168(OE) i2c_mux nouveau cx25840(OE) cx23885(OE) >>>> altera_ci(OE) tda18271(OE) altera_stapl(OE) videobuf2_dvb(OE) >>>> videobuf2_core(OE) videobuf2_dma_sg(OE) videobuf2_memops(OE) snd_seq >>>> snd_seq_device snd_pcm snd_timer snd video i2c_algo_bit ttm >>>> drm_kms_helper soundcore iTCO_wdt ppdev gpio_ich iTCO_vendor_support >>>> tveeprom(OE) cx2341x(OE) >>>> [ 506.969871] coretemp dvb_core(OE) v4l2_common(OE) videodev(OE) >>>> media(OE) kvm crc32c_intel raid456 async_raid6_recov async_memcpy >>>> async_pq async_xor drm xor async_tx raid6_pq microcode serio_raw shpchp >>>> i7core_edac edac_core i2c_i801 lpc_ich mfd_core parport_pc parport >>>> ite_cir(OE) rc_core(OE) tpm_infineon tpm_tis tpm acpi_cpufreq nfsd >>>> auth_rpcgss nfs_acl lockd sunrpc mxm_wmi asix usbnet r8169 mii wmi >>>> [ 506.969970] CPU: 0 PID: 3160 Comm: vb2-cx23885[0] Tainted: G >>>> OE 3.17.4-200.fc20.x86_64 #1 >>>> [ 506.969982] Hardware name: To Be Filled By O.E.M. To Be Filled By >>>> O.E.M./P55 Extreme, BIOS P2.70 08/20/2010 >>>> [ 506.969993] task: 8800bc18e220 ti: 88020d36c000 task.ti: >>>> 88020d36c000 >>>> [ 506.970002] RIP: 0010:[] [] >>>> vb2_thread+0x17a/0x480 [videobuf2_core] >>>> [ 506.970021] RSP: 0018:88020d36fe68 EFLAGS: 00010246 >>>> [ 506.970663] RAX: RBX: RCX: >>>> 000b >>>> [ 506.971305] RDX: 0058 RSI: 8800bc18e220 RDI: >>>> 0058 >>>> [ 506.971952] RBP: 88020d36fec0 R08: 88020d36c000 R09: >>>> 158f >>>> [ 506.972611] R10: 30de R11: 0010 R12: >>>> 0058 >>>> [ 506.973275] R13: 8800b81814a0 R14: R15: >>>> 880225c61028 >>>> [ 506.973947] FS: () GS:880233c0() >>>> knlGS: >>>> [ 506.974634] CS: 0010 DS: ES: CR0: 8005003b >>>> [ 506.975321] CR2: 0058 CR3: 01c14000 CR4: >>>> 07f0 >>>> [ 506.976021] Stack: >>>> [ 506.976723] 8800bc18e220 0070 00ff81c1b460 >>>> >>>> [ 506.977442] 8802 880225c61028 88020d1d8480 >>>> 880225c61028 >>>> [ 506.978165] a03a21c0 >>>> 88020d36ff48 >>>> [ 506.979055] Call Trace: >>>> [ 506.979795] [] ? vb2_internal_qbuf+0x210/0x210 >>>> [videobuf2_core] >>>> [ 506.980545] [] kthread+0xd8/0xf0 >>>> [ 506.981293] [] ? kthread_create_on_node >>>> +0x190/0x190 >>>> [ 506.982045] [] ret_from_fork+0x7c/0xb0 >>>> [ 506.982806] [] ? kthread_create_on_node >>>> +0x190/0x190 >>>
Re: Cpu Freq Merge with Scheduler
Robert, After doing some research I found on the lkml logs and through google that the latest discussion about this on the kernel lists was in 2013. I am curious as to where we are in terms of merging cpuidle and cpufreq into the scheduler, I known we have a basic patch series written in 2013 but seems that's about it. We also don't seem to have any test software to test this either. through seems there was some discussion at the plumber's conference in October of this year in Germany. Seems for my understanding we have hit a few roadblocks. 1. We have no benchmark tools, due to power management being hard to benchmark( lots of user cases) 2. Power Management is complex and doing a best fix all solution is impossible or near impossible 3. Merging cpuidle and cpufreq into the scheduler is a long and complex issue, we need to also benchmark and test for regressions as we are prone to error when merging these subsystems in the scheduler 4. This takes me back to my first point. we don't have have benchmark tools or a suite, therefore we shouldn't merge due to not being able to test for bugs or regressions we cause during the merge of these two subsystems into the scheduler. My question stands as follows have we got any farther on the above list of issues or not? Regards Nick On 2014-12-18 01:23 PM, Robert P. J. Day wrote: > Quoting nick : > >> Greetings Fellow Developers, > >> I am curious about the work going into making the kernel scheduler >> more CPU power efficient. I have done some googling on this and >> am curious about what how is going into the ideas/patches for this work. > >> Nick > >OFFS ... why are you asking about a clearly advanced kernel feature > on the kernel *newbies* list? And by the way, Nick, this is another > of your less endearing features -- your habit of posting one or two > line posts, effectively saying, "I am interested in topic , could > everyone drop what they're doing and explain it to me in astonishing > detail to save me the trouble of doing any work?" > >You've done this before -- the networking stack, BTRFS, and probably > more. Rather than do enough research to ask *detailed* and *specific* > questions, you instead simply request that people here explain something > to you, and it's getting kind of tiring. > >Do your own research. Stop asking everyone else to do it for you. > > rday > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Asus N53 USB WiFi Driver porting
On 2014-12-18 01:17 PM, Jeff Haran wrote: >> -Original Message- >> From: kernelnewbies-bounces+jeff.haran=citrix@kernelnewbies.org >> [mailto:kernelnewbies-bounces+jeff.haran=citrix@kernelnewbies.org] On >> Behalf Of nick >> Sent: Thursday, December 18, 2014 9:50 AM >> To: Greg KH; Abhishek Sharma >> Cc: valdis.kletni...@vt.edu; sant...@gmail.com; Abhishek Sharma; Kernel >> Newbies >> Subject: Re: Asus N53 USB WiFi Driver porting >> >> >> >> On 2014-12-18 11:26 AM, Greg KH wrote: >>> On Thu, Dec 18, 2014 at 08:18:24PM +0530, Abhishek Sharma wrote: >>>> Hi Valdis, >>>> Thanks for your reply. >>>> I do not want to change kernel. >>> >>> "do not want to" is very different from "applications can not be >>> ported to newer kernels". >>> >>> Please realize that the Linux kernel developers have spent the last >>> decade ensuring that you should be able to update to the latest kernel >>> version with no problems or changes needed in your applications. Lots >>> of companies now realize this and have no problem updating to a newer >>> kernel, while running their old applications. >>> >>> So please don't spread misinformation about how applications will >>> break with new kernel versions, that is almost always not a true statement. >>> >>> thanks, >>> >>> greg k-h >>> >>> ___ >>> Kernelnewbies mailing list >>> Kernelnewbies@kernelnewbies.org >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> >> Abhishek, >> I am to agree with Greg KH here. The kernel community does a very good job >> of not breaking APIs for applications or regressions. Linus also has openly >> stated >> he will not accept any patches in the main line kernel tree if they break >> user >> space so you should be fine. Further more to be honest I am very impressed >> with the amount of how little APIs or regressions we get compared to the >> amount of commits. Abhishek, in addition this seems more like you don't know >> or are afraid of compiling the kernel over anything else. If you want post >> lsmod >> output from your system so I can help teach you how to build the kernel >> correctly. >> Nick > > If it's a custom board, bringing up new kernel versions can be a quite > daunting task that the management of engineering organizations is more often > than not loathe to undertake. It can take a lot of education to convince them > that the pain and unpredictable development schedule hit of a kernel upgrade > is more than compensated for by the increases in stability and features one > gets when one goes through the process. > > Jeff Haran > Jeff, You are a 100% correct. I am assuming it wasn't a custom board but if it is them, you are right it's a lot of engineering work and time. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Cpu Freq Merge with Scheduler
Greetings Fellow Developers, I am curious about the work going into making the kernel scheduler more CPU power efficient. I have done some googling on this and am curious about what how is going into the ideas/patches for this work. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Asus N53 USB WiFi Driver porting
On 2014-12-18 11:26 AM, Greg KH wrote: > On Thu, Dec 18, 2014 at 08:18:24PM +0530, Abhishek Sharma wrote: >> Hi Valdis, >> Thanks for your reply. >> I do not want to change kernel. > > "do not want to" is very different from "applications can not be ported > to newer kernels". > > Please realize that the Linux kernel developers have spent the last > decade ensuring that you should be able to update to the latest kernel > version with no problems or changes needed in your applications. Lots > of companies now realize this and have no problem updating to a newer > kernel, while running their old applications. > > So please don't spread misinformation about how applications will break > with new kernel versions, that is almost always not a true statement. > > thanks, > > greg k-h > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > Abhishek, I am to agree with Greg KH here. The kernel community does a very good job of not breaking APIs for applications or regressions. Linus also has openly stated he will not accept any patches in the main line kernel tree if they break user space so you should be fine. Further more to be honest I am very impressed with the amount of how little APIs or regressions we get compared to the amount of commits. Abhishek, in addition this seems more like you don't know or are afraid of compiling the kernel over anything else. If you want post lsmod output from your system so I can help teach you how to build the kernel correctly. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Bad Commit for Current Lockups
Greetings, I send Dave, what I feel is the bad commit for the current lockups found in kernel 3.18 r4. The bad commit I believe is 4995ab9cf512e9a6cc07dfd6b1d4e2fc48ce7fef as it does touch the TLB code in the function that is most likely causing issues. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Filtering noise is about protecting resourses
Bjorn, I understand that now after reading your message. To be honest, I started out like this because I had no idea, where to start. If your willing to give me a place to start, that is of use I will be glad to help out. Over time, I hope we can work this out. Nick On 2014-12-09 04:24 AM, Bjørn Mork wrote: > Philipp Muhoray writes: > >> Not that I have any say in this, but I feel like a ban should rather >> be justified by someone's behavior instead of incorrect patches. > > It's not a ban, it's a protective filter. Maintainers and reviewers are > limited resources. We should not waste them. > >> I >> guess most of us have send awful patches at some point, the question >> though is how we dealt with it. I'm not saying the ban should be >> lifted, I'm just saying we should communicate the right arguments for >> his ban (instead of blaming him for commit messages he didn't even >> write). > > If you look at what actually happened, you'll see a very good example of > why the filter is still required: The original patch was yet another > completely pointless fixme-comment deletion, without any real > explanation whatsoever in the commit message. And it wasn't even > properly formatted with a subsystem prefixed subject etc. So the > maintainer had to spend time trying to fix up the commit message and > figuring out why it was OK to delete those fixme comments. As has been > pointed out here, that explanation could still be incomplete. I guess > the maintainer didn't want to spend hours looking at something as > pointless as this. The problem is that he didn't realize that this > patch was a waste of time before spending time on it at all. > > Which is exactly why the maintainers should be protected against having > to look at stuff like this, if possible. And in this case it *is*. > There are exactly zero examples of valuable patches from that author. > If you look at the history of accepted patches, you will find that in > each and every case there is some reviewer or maintainer doing the > *real* work - figuring out that the patch is OK and explaining why. And > the result is still patches without any real value. They don't solve > any problem for anyone. They are the result of stupid and mindless > grepping for a specific word in comments. > > Yes, we have all wasted time for maintainers and reviewers by sending > them stuff we shouldn't have. That's part of the game. The problem in > this case is the massive distribution over an insane number of > subsystems in combination with the inability to learn anything at all. > Wasting one maintainer's time once is excusable. Wasting hundreds of > maintainer's time over and over again is absolutely not. It's > potentionally destructive to the whole project if it is allowed to > continue. > > This very thread is yet another example of the contentless noise from > this source, and I hate myself for having wasted your time having to > read this. Sorry about that. > > But I write it in the hope that you will understand that the filtering > is *not* about punishing anyone. It is about protecting or most valuable > resources. > > And if anyone still wonders: Requests for "ban removal" has no value to > the community, and are therefore the exact opposite of what's required > to have the filter removed. > > > Bjørn > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Remove Ban?
On Mon, Dec 8, 2014 at 10:32 AM, wrote: > On Sun, 07 Dec 2014 22:15:13 -0500, nick said: >> Greetings Fellow Developers, >> I have finally learned my lesson as you can tell from my newest patches being >> accepted or considered in good form. > > Right now,all I'm seeing in linux-next from you is 2 patches that > remove FIXME comments. Given your previous history of submitting > patches that failed to accurately analyze C program flow, And the > commit message on one of them: > > Remove FIXME comments about needing fault addresses to be returned. These > are propaagated from walk_addr_generic to gva_to_gpa and from there to > ops->read_std and ops->write_std. > > doesn't actually address the question of how to deal with fault addresses. > Yes, they're propagated back - but it doesn't directly address the question > of how a fault address is handled (in other words, you failed to show that > write_std actually does the right thing once it gets whatever we send back) > > I wouldn't hold my breath I submitted the patch. The maintainer changed the commit message not me. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Remove Ban?
Greetings Fellow Developers, I have finally learned my lesson as you can tell from my newest patches being accepted or considered in good form. In addition if people are willing to trust me again, I would like to remove my ban in order to help out more. If not I understand completely and will try to improve my trust from the developers on the kernel list even more. Thanks for the Understanding, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: stability ?
I agree with Valdis here, unlike user space the kernel has too many weird use cases on different hardware or configs for one developer to test alone. Through Intel does have their test lab for Linux now :). Regards Nick On 2014-12-04 10:02 AM, valdis.kletni...@vt.edu wrote: > On Thu, 04 Dec 2014 11:37:45 +0800, libin said: >> Does anybody know what test should do before a patch added into the >> kernel ? I am interested in the method to prove the stability and performance >> of kernel , especially the stability . > > That will of course be *heavily* dependent on the exact nature of the > patch. The Linux kernel is developed with a "lots of small incremental > patches" philosophy. As a result, most patches are relatively minor > and only require testing that they work - so if it compiles, boots, and > you test whatever function the patch does, that's sufficient. Your webcam > now outputs RGB like it should, not GBR like it was? Excellent. The ethernet > driver no longer crashes when it sees a packet that's exactly 1397 bytes > long? Great. Package it up and submit it. > > If you're adding new functionality, you of course want to test a bit more. > > Boot the kernel, and let it run for a few days, make sure you don't have > any memory leaks or stray pointers or other crashes. That's probably all > the testing most patches actually get. And that's OK, most well-written > patches don't *need* more testing. > > If you're ambitious and writing patches that are more invasive, get xfstests > and/or the Linux Test Project package and run those against your new kernel. > Note that you may need to write new test routines if you added new function. > > If you're *really* hardcore, get 'trinity' and run that against your kernel. > Make sure to back the test system up first, it *can* eat your system. > > The *real* problem is that the Linux kernel ends up getting used in lots > of weird configurations - far too many for any developer to test. And > stability > issues come in two flavors: Ones that kill your own box in an hour of light > use, and ones that only happen on a very small number of systems, none of them > yours. > > I personally manage to trip over 3-4 bugs in linux-next each release cycle, > just because I do stuff on my Dell laptop that developers obviously didn't > have a way to test. For instance, right now I'm trying to track down a > nasty bug in drivers/net/tun.c where it's pretty obvious that the guy who > wrote the commit tested what he could (he has a reputation of doing good > work), but the Juniper VPN software my employer uses gives it indigestion. > Wasn't any way for Herbert to test that one without a Juniper VPN box to > test against... > > Linus had a *long* chase after one bug, that turned out two be two > instructions in the wrong order in an asm() statement, which would lead to > a system hang if an interrupt came in between the two instructions. So > there was a race condition window *literally* 2 cycles wide - and *one* user > had a workload that was able to pretty frequently drop an interrupt into > that billionth of a second window. Frequent as in "managed that impossible > shot several times a day" > > And the only real way to find that sort of weirdness is to get the patch into > linux-next and then have lots of linux-next testers with different use > cases > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Interested in Networking, Memory and Btrfs Subsystems
Greetings Fellow Kernel Developers, I am wondering if anyone would mind mentoring me in any of the three areas listed in my subject message. Further more I understand if no one accepts this offer due to my bad rep. Finally, after wasting some many people's time I am starting to write good patches as people can see from the logs of LKML. :) Thanks for the Help, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: The limit of kernel memory in 64bit system
Sorry Yiqun, I was thinking of virtual memory so you are correct. I also haven't looked into the kernel memory subsystem(s) in a while so I may be a little behind in my knownledge of them. Regards Nick On 2014-11-29 03:54 PM, Yiqun Chen wrote: > Incorrect. The 64 bit machine theoretically supports 2 ^ 64 bytes virtual > memory space but on x86 only 48 out of 64 address buses are used. So we > cannot assume the upper limit of physical space.on different platforms. > And Nick you're confusing with the physical and virtual memory. The usage > of memory for kernel space is not determined by the ratio. It's defined by > mapping strategy. You first need to know why this 3 to 1 was used. It's > because we cannot map all the physical pages onto the corresponding virtual > address since we need to spare some linear space for user program. But on > 64 bits platform we have plenty virtual address for the programmer as the > physical memory is much much smaller than it. On x86_64 we divide > kernel/user space by setting all the first 16 bits with 0 or 1 as the user > or kernel space respectfully. So how large would the kernel space be if we > could use 48-bit linear space? > > On Sat, Nov 29, 2014 at 8:16 PM, nick wrote: > >> J.Hwan, >> There is a limit as 64 bit can only support 16 extabytes. Greg is right in >> that there is no real limit >> on modern machines because of this. However from my knowledge, system ram >> is split into a 3 to 1 ratio, >> where 75 percent is for user space and the only quarter is for the >> kernel's memory. So on my system with >> 8 GB of ram, the kernel can use up to 25 percent or 2 GB of ram. >> Hope this answers your question, >> Nick >> On 2014-11-29 12:45 PM, Greg KH wrote: >>> On Sat, Nov 29, 2014 at 12:25:43AM +0900, J.Hwan Kim wrote: >>>> Hi, everyone >>>> >>>> As far as I know, the kernel memory limit is 1GB in 32bit system. >>>> Is it also applicable to 64bit system? >>>> What's the limit of kernel memory in 64bit system? >>> >>> There is no limit :) >>> >>> What do you really want to know this for? >>> >>> greg k-h >>> >>> ___ >>> Kernelnewbies mailing list >>> Kernelnewbies@kernelnewbies.org >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> >> >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > > > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: The limit of kernel memory in 64bit system
J.Hwan, There is a limit as 64 bit can only support 16 extabytes. Greg is right in that there is no real limit on modern machines because of this. However from my knowledge, system ram is split into a 3 to 1 ratio, where 75 percent is for user space and the only quarter is for the kernel's memory. So on my system with 8 GB of ram, the kernel can use up to 25 percent or 2 GB of ram. Hope this answers your question, Nick On 2014-11-29 12:45 PM, Greg KH wrote: > On Sat, Nov 29, 2014 at 12:25:43AM +0900, J.Hwan Kim wrote: >> Hi, everyone >> >> As far as I know, the kernel memory limit is 1GB in 32bit system. >> Is it also applicable to 64bit system? >> What's the limit of kernel memory in 64bit system? > > There is no limit :) > > What do you really want to know this for? > > greg k-h > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Advantages in Scalability of Softriqs versus Tasklets
I am curious about reading through LKD, when to start using softriqs other tasklets in terms of when the limit of scalability of tasklets are hit. I am assuming after reading LKD it seems to happen when multiple cores would be of great advantage in scaling the bottom half of my or our people's code. In addition in seems to also happen when timing of interrupts needs to be in the range of under milliseconds to process the bottom half and this seems very important for the networking subsystem. Cheers and Thanks for Any Answers, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Re Start Fresh
I am attaching a patch, here that I assume is trivial but good. This is in order
to prove I am serious about this.
Nick
On 14-11-13 11:20 AM, valdis.kletni...@vt.edu wrote:
> On Thu, 13 Nov 2014 10:02:42 -0500, Nick Krause said:
>> I am willing to start out completely fresh and willing to learn how to
>> do this correctly now and hopefully improve my rep ... slowly.
>> This is not another email for me trying to state again I am willing
>> to change,
>
> That's odd, that's what it *reads* like it is.
>
>>I really would like to help me out and am not sure where
>> to start in order to improve my rep.
>
> Deeds, not words.
>
>From c9bb6796cb18580d7d7dd98be18231e4374f84a5 Mon Sep 17 00:00:00 2001
From: Nicholas Krause
Date: Thu, 30 Oct 2014 22:35:29 -0400
Subject: [PATCH] drivers: Fix typos in rt2800lib.c and oxu210hp-hcd.c
Changes a typo of fimxe to fixme in the files,rtl2800lib.c and
oxu210hp-hcd.c.
Signed-off-by: Nicholas Krause
---
drivers/net/wireless/rt2x00/rt2800lib.c | 2 +-
drivers/usb/host/oxu210hp-hcd.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 9f57a2d..14d6a5d 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2843,7 +2843,7 @@ static void rt2800_config_channel_rf55xx(struct rt2x00_dev *rt2x00dev,
ep_reg = 0x2;
} else {
rt2800_rfcsr_write(rt2x00dev, 10, 0x97);
- /* FIMXE: RF11 overwrite */
+ /* FIXME: RF11 overwrite */
rt2800_rfcsr_write(rt2x00dev, 11, 0x40);
rt2800_rfcsr_write(rt2x00dev, 25, 0xBF);
rt2800_rfcsr_write(rt2x00dev, 27, 0x42);
diff --git a/drivers/usb/host/oxu210hp-hcd.c b/drivers/usb/host/oxu210hp-hcd.c
index 4fe79a2..2ef5d59 100644
--- a/drivers/usb/host/oxu210hp-hcd.c
+++ b/drivers/usb/host/oxu210hp-hcd.c
@@ -2677,7 +2677,7 @@ static int oxu_reset(struct usb_hcd *hcd)
INIT_LIST_HEAD(&oxu->urb_list);
oxu->urb_len = 0;
- /* FIMXE */
+ /* FIXME */
hcd->self.controller->dma_mask = NULL;
if (oxu->is_otg) {
--
1.9.1
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re Start Fresh
I am willing to start out completely fresh and willing to learn how to do this correctly now and hopefully improve my rep ... slowly. This is not another email for me trying to state again I am willing to change, I really would like to help me out and am not sure where to start in order to improve my rep. Cheers Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Learning From Mistakes
Greetings other developers, After the past few months , I have learned how shitty my patches were initially to the LKML. I am willing to start submitting good patches, if people are willing to give me a second try and this is not one of my many emails for trying and getting it wrong. I really want to start building my trust and relationships again with the maintainers and other developers who's time I so ungratefully wasted. Sorry and I appreciate any replies, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: Fix spacing between function name and parentheses
Greetings Bjorn and others,
I sent this patch a few weeks ago and am really trying to to improve my rep
here by sending solid patches.
In addition I understand the caution with my patches due to my terrible rep but
it would be nice if someone
sends or acknowledges the patch as other people on this list have stated it's
correct and good in previous
emails to me.
Nick
On 14-11-03 05:05 AM, Bjørn Mork wrote:
> valdis.kletni...@vt.edu writes:
>> On Mon, 20 Oct 2014 09:17:50 -, el_es said:
>>
>>> Maybe better to introduce a standard clear marker that
>>> able people just respond with, to alikes of nick:
>>>
>>> REJECTED-by: Name
>>
>> We already do something like this.
>>
>> You'll on occasion see 'Nacked-By: ...' go by when a kernel hacker
>> wants to denote their displeasure with a given patch. It's up to the
>> maintainer to decide how much credence to give to the Nack, based on the
>> relative reputations of the person submitting the patch and the person
>> nacking it, and any technical grounds given with the nack.
>>
>> So for instance, if Al Viro sticks a Nacked-By: on a submission, it's
>> going to be *really* hard to get a maintainer to accept the patch, because
>> Al has a very long history of almost always being right about such things.
>
> Yes, but the technical grounds are still the reason the patch is not
> accepted. Which is why a formalized nak is pointless. It has no value
> without a verbose explanation of the technical grounds behind it. If Al
> Viro, or anyone else, use a simple one-line reject message, then I am
> pretty sure that is because they have already explained their objections
> somewhere else. I don't think anyone can reject anything merely on their
> personal reputation. And there is nowhere to record naks, so a standard
> label just isn't needed.
>
> Rejecting is completely different from e.g. Acked-by, which both is a
> complete explanation ("I am fine with this patch as it is") and is
> recorded for future reference in the commit message.
>
>
> Bjørn
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Fwd: Re: [PATCH] staging: Fix checkpatch error messages about unneeded space before commas in ms.c
Forwarded Message Subject: Re: [PATCH] staging: Fix checkpatch error messages about unneeded space before commas in ms.c Date: Sun, 2 Nov 2014 15:56:36 +0100 From: Peter Senna Tschudin To: Nicholas Krause This is good! You can try to submit it. On Tue, Oct 28, 2014 at 9:25 PM, Nicholas Krause wrote: > Fixes various checkpatch error messages about removing unneeded spaces before > commas on > certain lines in ms.c. > > Signed-off-by: Nicholas Krause > --- > drivers/staging/rts5208/ms.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/staging/rts5208/ms.c b/drivers/staging/rts5208/ms.c > index 228e483..d77153c 100644 > --- a/drivers/staging/rts5208/ms.c > +++ b/drivers/staging/rts5208/ms.c > @@ -781,7 +781,7 @@ static int msxc_change_power(struct rtsx_chip *chip, u8 > mode) > buf[4] = 0; > buf[5] = 0; > > - retval = ms_write_bytes(chip, PRO_WRITE_REG , 6, NO_WAIT_INT, buf, 6); > + retval = ms_write_bytes(chip, PRO_WRITE_REG, 6, NO_WAIT_INT, buf, 6); > if (retval != STATUS_SUCCESS) > TRACE_RET(chip, STATUS_FAIL); > > @@ -1291,7 +1291,7 @@ static int ms_write_extra_data(struct rtsx_chip *chip, > for (i = 6; i < MS_EXTRA_SIZE + 6; i++) > data[i] = buf[i - 6]; > > - retval = ms_write_bytes(chip, WRITE_REG , (6+MS_EXTRA_SIZE), > + retval = ms_write_bytes(chip, WRITE_REG, (6+MS_EXTRA_SIZE), > NO_WAIT_INT, data, 16); > if (retval != STATUS_SUCCESS) > TRACE_RET(chip, STATUS_FAIL); > @@ -1342,7 +1342,7 @@ static int ms_read_page(struct rtsx_chip *chip, u16 > block_addr, u8 page_num) > data[4] = 0x20; > data[5] = page_num; > > - retval = ms_write_bytes(chip, WRITE_REG , 6, NO_WAIT_INT, data, 6); > + retval = ms_write_bytes(chip, WRITE_REG, 6, NO_WAIT_INT, data, 6); > if (retval != STATUS_SUCCESS) > TRACE_RET(chip, STATUS_FAIL); > > @@ -1619,7 +1619,7 @@ static int ms_copy_page(struct rtsx_chip *chip, u16 > old_blk, u16 new_blk, > data[4] = 0x20; > data[5] = i; > > - retval = ms_write_bytes(chip, WRITE_REG , 6, NO_WAIT_INT, > + retval = ms_write_bytes(chip, WRITE_REG, 6, NO_WAIT_INT, > data, 6); > if (retval != STATUS_SUCCESS) > TRACE_RET(chip, STATUS_FAIL); > @@ -1988,7 +1988,7 @@ RE_SEARCH: > RTSX_WRITE_REG(chip, PPBUF_BASE2, 0xFF, 0x88); > RTSX_WRITE_REG(chip, PPBUF_BASE2 + 1, 0xFF, 0); > > - retval = ms_transfer_tpc(chip, MS_TM_WRITE_BYTES, WRITE_REG , > 1, > + retval = ms_transfer_tpc(chip, MS_TM_WRITE_BYTES, WRITE_REG, > 1, > NO_WAIT_INT); > if (retval != STATUS_SUCCESS) > TRACE_RET(chip, STATUS_FAIL); > -- > 1.9.1 > -- Peter ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: rtl8723au: Fix brace coding style issues reported by checkpatch
I am trying to improve my rep first through. Cheers Nick On 14-10-30 12:21 AM, Sudip Mukherjee wrote: > On Thu, Oct 30, 2014 at 5:34 AM, nick wrote: >> I don't mind waiting. I am just honestly trying to improve my rep here and >> actually(hopefully) get a job >> doing this full time. > > great , even if i want to get into a job where i can do this full time > , and hopefully everyone here does, > I dont want to discourage you , but considering your reputation (all > over the world - maybe even outside this world) , that might be > difficult. > >> Cheers Nick >> >> On 14-10-29 04:45 AM, Scott Lovenberg wrote: >>> On Wed, Oct 29, 2014 at 1:48 AM, Sudip Mukherjee >>> wrote: >>>> On Wed, Oct 29, 2014 at 11:38 AM, Scott Lovenberg >>>> wrote: >>>>> On Wed, Oct 29, 2014 at 12:05 AM, Sudip Mukherjee >>>>> wrote: >>>>>> >>>>>> On Wed, Oct 29, 2014 at 7:31 AM, nick wrote: >>>>>>> Greg, >>>>>>> That's fine, I was wondering how long Greg KH takes to get around to >>>>>>> picking this up as he is very busy with >>>>>>> other kernel work. >>>>>> >>>>>> it might take a long long time. i think he is very busy now. I have >>>>>> not seen his replies to patches in the kernel list for atleast last 3 >>>>>> weeks. >>>>>> >>>>> [snip] >>>>>> >>>>>> ___ >>>>>> Kernelnewbies mailing list >>>>>> Kernelnewbies@kernelnewbies.org >>>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>>>> >>>>> >>>>> >>>>> Nah. Greg KH is a robot. I'm firmly convinced that man doesn't >>>>> sleep. If I didn't know better, I'd think he's a Cylon. >>>> well said. >>>> >>>>> On a serious note; realistically, a two week window isn't unheard of >>>>> for getting your patches to mainline. So long as you're not trying to >>>> >>>> mine is three weeks going on now. somehow i have managed to send my >>>> patches just at the beginning of the merge window. :( >>>> yesterday i saw Greg K-H releasing the stable patches , so i guess now >>>> he will be seeing the pending staging patches. >>> >>> It also depends on how many hops you are to the maintainer and how >>> heavy their workload is. Sometimes you can directly submit to them, >>> other times your patches will be passed through three trees before >>> they see mainline. It all depends on what you're working on and who's >>> in your "circle". >>> ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: rtl8723au: Fix brace coding style issues reported by checkpatch
I don't mind waiting. I am just honestly trying to improve my rep here and actually(hopefully) get a job doing this full time. Cheers Nick On 14-10-29 04:45 AM, Scott Lovenberg wrote: > On Wed, Oct 29, 2014 at 1:48 AM, Sudip Mukherjee > wrote: >> On Wed, Oct 29, 2014 at 11:38 AM, Scott Lovenberg >> wrote: >>> On Wed, Oct 29, 2014 at 12:05 AM, Sudip Mukherjee >>> wrote: >>>> >>>> On Wed, Oct 29, 2014 at 7:31 AM, nick wrote: >>>>> Greg, >>>>> That's fine, I was wondering how long Greg KH takes to get around to >>>>> picking this up as he is very busy with >>>>> other kernel work. >>>> >>>> it might take a long long time. i think he is very busy now. I have >>>> not seen his replies to patches in the kernel list for atleast last 3 >>>> weeks. >>>> >>> [snip] >>>> >>>> ___ >>>> Kernelnewbies mailing list >>>> Kernelnewbies@kernelnewbies.org >>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> >>> >>> >>> Nah. Greg KH is a robot. I'm firmly convinced that man doesn't >>> sleep. If I didn't know better, I'd think he's a Cylon. >> well said. >> >>> On a serious note; realistically, a two week window isn't unheard of >>> for getting your patches to mainline. So long as you're not trying to >> >> mine is three weeks going on now. somehow i have managed to send my >> patches just at the beginning of the merge window. :( >> yesterday i saw Greg K-H releasing the stable patches , so i guess now >> he will be seeing the pending staging patches. > > It also depends on how many hops you are to the maintainer and how > heavy their workload is. Sometimes you can directly submit to them, > other times your patches will be passed through three trees before > they see mainline. It all depends on what you're working on and who's > in your "circle". > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: rtl8723au: Fix brace coding style issues reported by checkpatch
Sorry Jeff, My fault, mistyped. Cheers Nick On 14-10-28 10:04 PM, Jeff Kirsher wrote: > On Tue, 2014-10-28 at 22:01 -0400, nick wrote: >> Greg, >> That's fine, I was wondering how long Greg KH takes to get around to picking >> this up as he is very busy with >> other kernel work. >> Cheers Nick > > I am Jeff and I was the one that responded... > >> >> On 14-10-28 09:58 PM, Jeff Kirsher wrote: >>> On Tue, 2014-10-28 at 21:49 -0400, nick wrote: >>>> Greg, >>>> Not picked up of yet. I would appreciate if this gets forwarded for me as >>>> this may help it get picked up. >>>> Further more this issues I am were causing were not technical but not >>>> listening and that's why I decided >>>> to state around and learn how to my patches properly. >>>> Cheers Nick >>>> >>> >>> I saw you updated you patch Nick, thanks. I feel I can safely put my >>> Reviewed-by: on it. Also, if Greg KH (staging maintainer) has not >>> picked up in the next day or so, I will submit your patch to the staging >>> tree for you. >>> >>>> >>>> On 14-10-28 05:31 PM, Greg Donald wrote: >>>>> On Tue, Oct 28, 2014 at 2:52 PM, nick wrote: >>>>>> I am trying to improve my code as much as possible now, I really am >>>>>> finally understanding >>>>>> how terrible my code was before and I hope never again to make patches >>>>>> that shitty. >>>>> >>>>> I don't think your recent progress has gone unnoticed. Any word on >>>>> your latest patch getting picked up? It looked good to me. >>>>> >>>>> You remind me of John Locke from Lost. "Don't tell me what I can't do!" >>>>> :) >>>>> >>>>> >>> >>> > > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: rtl8723au: Fix brace coding style issues reported by checkpatch
Greg, That's fine, I was wondering how long Greg KH takes to get around to picking this up as he is very busy with other kernel work. Cheers Nick On 14-10-28 09:58 PM, Jeff Kirsher wrote: > On Tue, 2014-10-28 at 21:49 -0400, nick wrote: >> Greg, >> Not picked up of yet. I would appreciate if this gets forwarded for me as >> this may help it get picked up. >> Further more this issues I am were causing were not technical but not >> listening and that's why I decided >> to state around and learn how to my patches properly. >> Cheers Nick >> > > I saw you updated you patch Nick, thanks. I feel I can safely put my > Reviewed-by: on it. Also, if Greg KH (staging maintainer) has not > picked up in the next day or so, I will submit your patch to the staging > tree for you. > >> >> On 14-10-28 05:31 PM, Greg Donald wrote: >>> On Tue, Oct 28, 2014 at 2:52 PM, nick wrote: >>>> I am trying to improve my code as much as possible now, I really am >>>> finally understanding >>>> how terrible my code was before and I hope never again to make patches >>>> that shitty. >>> >>> I don't think your recent progress has gone unnoticed. Any word on >>> your latest patch getting picked up? It looked good to me. >>> >>> You remind me of John Locke from Lost. "Don't tell me what I can't do!" :) >>> >>> > > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: rtl8723au: Fix brace coding style issues reported by checkpatch
Greg, Not picked up of yet. I would appreciate if this gets forwarded for me as this may help it get picked up. Further more this issues I am were causing were not technical but not listening and that's why I decided to state around and learn how to my patches properly. Cheers Nick On 14-10-28 05:31 PM, Greg Donald wrote: > On Tue, Oct 28, 2014 at 2:52 PM, nick wrote: >> I am trying to improve my code as much as possible now, I really am finally >> understanding >> how terrible my code was before and I hope never again to make patches that >> shitty. > > I don't think your recent progress has gone unnoticed. Any word on > your latest patch getting picked up? It looked good to me. > > You remind me of John Locke from Lost. "Don't tell me what I can't do!" :) > > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: rtl8723au: Fix brace coding style issues reported by checkpatch
Hey Greg, I am trying to improve my code as much as possible now, I really am finally understanding how terrible my code was before and I hope never again to make patches that shitty. Cheers Nick On 14-10-28 02:06 PM, Greg Donald wrote: > On Tue, Oct 28, 2014 at 12:53 PM, Nick Krause wrote: >> I actually fixed this to improve code readability not for the kernel >> rules for your information. > > I know, good job.. and here's to hoping a maintainer picks up your > patch and applies it to their tree :) > > But I would argue "kernel rules" and "improving code readability" are > one and the same. Otherwise checkpatch and it's optional -f needn't > exist. > > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: rtl8723au: Fix brace coding style issues reported by checkpatch
On Tue, Oct 28, 2014 at 1:39 PM, Greg Donald wrote: > On Tue, Oct 28, 2014 at 11:50 AM, Greg Freemyer > wrote: >> Lots of violations >> checkpatch finds are intentionally left in place because correcting >> them makes the code less readable, not more readable. > > Yeah, but there are still hundreds of thousands of checkpatch > violations throughout the kernel that if fixed would actually improve > readability. > > PathErrors Warnings > drivers 200979 361350 > arch98791 142300 > sound 25938 31028 > include 13651 25598 > fs 96353 22483 > net 318519216 > lib 80556578 > tools 11263972 > kernel 656 3203 > security47 1247 > mm 203 1186 > scripts 824 1168 > crypto 11441095 > block 196 656 > Documentation 97 259 > init29 173 > virt18 152 > samples 27 118 > ipc 2 77 > usr 17 20 > firmware11 19 > > The WARNING "line over 80 characters" currently accounts for 216K of > the total violations. IMHO checkpatch should just stop complaining > about the 80 char limit since that's the main offender causing new > kernel developers to inadvertently lessen readability with their first > patch. If the 80 char warning should be mostly ignored why have it.. > it's pointless. Increase it to a 21st century value or kill it. > > > -- > Greg Donald I actually fixed this to improve code readability not for the kernel rules for your information. Cheers Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: Fix checkpatch issue with brackets in rtw_ap.c
Good to hear, I will try tomorrow to send it a correct patch fixing out the
issues like the one found
in this patch in the same file. I am pretty certain I known how to do a patch
how.
Nick
On 14-10-22 12:50 AM, Sudip Mukherjee wrote:
> On Tue, Oct 21, 2014 at 08:31:25PM -0700, Jeff Kirsher wrote:
>> On Tue, Oct 21, 2014 at 10:34 AM, Nicholas Krause
>> wrote:
>>> Fix checkpatch error message with opening bracket of if statement,
>>> not being on the same line as a if statement in rtw_ap.c
>>>
>>> Signed-off-by: Nicholas Krause
>>> ---
>>> drivers/staging/rtl8723au/core/rtw_ap.c | 3 +--
>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> I will say, it does appear you finally got a patch right. Only issue
> i agree to that. Finally Nick has sent a patch which is not having any style
> error, applies properly , doesnot change the logic.
>> I have is that you corrected only one of the many instances of the
>> same problem in this file.
>> If you are going to correct one instance, might as well fix them all.
> don't you think if he tries to fix them all at one go, he will again mess up
> everything ?
>
> thanks
> sudip
>>
>>>
>>> diff --git a/drivers/staging/rtl8723au/core/rtw_ap.c
>>> b/drivers/staging/rtl8723au/core/rtw_ap.c
>>> index 6b4092f..927b2a6 100644
>>> --- a/drivers/staging/rtl8723au/core/rtw_ap.c
>>> +++ b/drivers/staging/rtl8723au/core/rtw_ap.c
>>> @@ -1567,8 +1567,7 @@ void bss_cap_update_on_sta_join23a(struct rtw_adapter
>>> *padapter, struct sta_info
>>> }
>>> }
>>>
>>> - if (rtw_ht_operation_update(padapter) > 0)
>>> - {
>>> + if (rtw_ht_operation_update(padapter) > 0) {
>>> update_beacon23a(padapter, WLAN_EID_HT_CAPABILITY, NULL,
>>> false);
>>> update_beacon23a(padapter, WLAN_EID_HT_OPERATION, NULL,
>>> true);
>>> }
>>> --
>>> 1.9.1
>>>
>>>
>>> ___
>>> Kernelnewbies mailing list
>>> Kernelnewbies@kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>>
>> --
>> Cheers,
>> Jeff
>>
>> ___
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
USB Start Learning Codebase
Hey Guys, I am asking here about how to start with the usb stack as I am interested in learning that alongside the btrfs codebase. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: Fix spacing between function name and parentheses
Valdis, I do understand your concern with me finding one of the few false positives, due to my issues already with the community. I am trying my best now to improve and work toward good,solid work that is of actual use to the community and avoid shitty patches and not listening like I did for the last few months. Sorry, Nick On 14-10-12 06:34 PM, valdis.kletni...@vt.edu wrote: > On Sat, 11 Oct 2014 14:52:40 +0100, Hugo Mills said: > >> On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote: >>> Thank you for your help, I'll study the code and see what I can do >>> about it. Do you have any suggestions of how to fix this checkpatch >>> warning? >> >>Ignore it. The checker has clearly triggered on a false positive -- >> this is not a function call, and should not be held to that standard. >> (Take a look at where the macro is actually used, to see what's going >> on here). Move on to find something more interesting to fix. > > Am I the only one suspicious of the fact that Nick found one of the > few false positives rather than one of the plentiful actual style > problems? > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: Fix spacing between function name and parentheses
Great to known. Sorry about not reading the code, will check more carefully
before I fix it.
Regards Nick
On 14-10-11 11:25 AM, karthik nayak wrote:
> Hey Nick,
> Nice try to fix a checkpatch warning. But do read what you're changing.
> Yes your format is right. If you haven't already, take a look at "git
> send-email" .
> Have fun hacking :D
> Regards,
> Karthik Nayak
>
>
> On Sat, Oct 11, 2014 at 7:47 PM, nick wrote:
>> Thanks Hugo,
>> Sorry about that. On the other hand was the patch good in terms of format?
>> Cheers Nick
>>
>> On 14-10-11 09:52 AM, Hugo Mills wrote:
>>> On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote:
>>>> Thank you for your help, I'll study the code and see what I can do
>>>> about it. Do you have any suggestions of how to fix this checkpatch
>>>> warning?
>>>
>>>Ignore it. The checker has clearly triggered on a false positive --
>>> this is not a function call, and should not be held to that standard.
>>> (Take a look at where the macro is actually used, to see what's going
>>> on here). Move on to find something more interesting to fix.
>>>
>>>Hugo.
>>>
>>>> Nick
>>>>
>>>> On 14-10-11 05:53 AM, Kristofer Hallin wrote:
>>>>> Even if you use checkpath you _should_ understand what you are changing.
>>>>> The output of checkpatch merely there to help.
>>>>>
>>>>> In this case you can see that this is a macro just a few lines up in the
>>>>> code.
>>>>> On 11 Oct 2014 11:46, "Sudip Mukherjee"
>>>>> wrote:
>>>>>
>>>>>> I agree. But in my opinion checkpatch is here to help us fix style
>>>>>> problems , but we should not blindly act on checkpatch warnings.
>>>>>>
>>>>>> thanks
>>>>>> sudip
>>>>>>
>>>>>> On Sat, Oct 11, 2014 at 1:57 PM, Peter Senna Tschudin
>>>>>> wrote:
>>>>>>> I think that, in this case, checkpatch.pl contributed:
>>>>>>>
>>>>>>> $ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>> WARNING: space prohibited between function name and open parenthesis '('
>>>>>>> #415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415:
>>>>>>> + if (c.s.field op (value)) {
>>>>>>\
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian
>>>>>> wrote:
>>>>>>>> Agreed - that is why I mentioned the patch is neither right nor
>>>>>>>> useful:)
>>>>>>>>
>>>>>>>> -daveti
>>>>>>>>
>>>>>>>>
>>>>>>>> On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee <
>>>>>> sudipm.mukher...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Dave,
>>>>>>>>> It will work. But my point of saying that was c.s.field ==(value) is
>>>>>>>>> again not according to the style.
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> sudip
>>>>>>>>>
>>>>>>>>> On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian
>>>>>> wrote:
>>>>>>>>>> It also works as value is surrounded by (), though I do not think the
>>>>>> patch itself is right or useful.
>>>>>>>>>>
>>>>>>>>>> Dave Tian
>>>>>>>>>> dave.jing.t...@gmail.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <
>>>>>> sudipm.mukher...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
>>>>>>>>>>>> Fixes checkpatch coding style warning about unneeded space
>>>>>>>>>>>> between function name an parentheses.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Nicholas Krause
>>>&
Re: [PATCH] staging: Fix spacing between function name and parentheses
Thanks Hugo,
Sorry about that. On the other hand was the patch good in terms of format?
Cheers Nick
On 14-10-11 09:52 AM, Hugo Mills wrote:
> On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote:
>> Thank you for your help, I'll study the code and see what I can do
>> about it. Do you have any suggestions of how to fix this checkpatch
>> warning?
>
>Ignore it. The checker has clearly triggered on a false positive --
> this is not a function call, and should not be held to that standard.
> (Take a look at where the macro is actually used, to see what's going
> on here). Move on to find something more interesting to fix.
>
>Hugo.
>
>> Nick
>>
>> On 14-10-11 05:53 AM, Kristofer Hallin wrote:
>>> Even if you use checkpath you _should_ understand what you are changing.
>>> The output of checkpatch merely there to help.
>>>
>>> In this case you can see that this is a macro just a few lines up in the
>>> code.
>>> On 11 Oct 2014 11:46, "Sudip Mukherjee" wrote:
>>>
>>>> I agree. But in my opinion checkpatch is here to help us fix style
>>>> problems , but we should not blindly act on checkpatch warnings.
>>>>
>>>> thanks
>>>> sudip
>>>>
>>>> On Sat, Oct 11, 2014 at 1:57 PM, Peter Senna Tschudin
>>>> wrote:
>>>>> I think that, in this case, checkpatch.pl contributed:
>>>>>
>>>>> $ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c
>>>>> WARNING: space prohibited between function name and open parenthesis '('
>>>>> #415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415:
>>>>> + if (c.s.field op (value)) {
>>>>\
>>>>>
>>>>>
>>>>> On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian
>>>> wrote:
>>>>>> Agreed - that is why I mentioned the patch is neither right nor useful:)
>>>>>>
>>>>>> -daveti
>>>>>>
>>>>>>
>>>>>> On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee <
>>>> sudipm.mukher...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Dave,
>>>>>>> It will work. But my point of saying that was c.s.field ==(value) is
>>>>>>> again not according to the style.
>>>>>>>
>>>>>>> thanks
>>>>>>> sudip
>>>>>>>
>>>>>>> On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian
>>>> wrote:
>>>>>>>> It also works as value is surrounded by (), though I do not think the
>>>> patch itself is right or useful.
>>>>>>>>
>>>>>>>> Dave Tian
>>>>>>>> dave.jing.t...@gmail.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <
>>>> sudipm.mukher...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
>>>>>>>>>> Fixes checkpatch coding style warning about unneeded space
>>>>>>>>>> between function name an parentheses.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Nicholas Krause
>>>>>>>>>> ---
>>>>>>>>>> Untested
>>>>>>>>>> drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
>>>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/staging/octeon-usb/octeon-hcd.c
>>>> b/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>>>>> index 5f9db4c..bbeb0cc 100644
>>>>>>>>>> --- a/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>>>>> +++ b/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>>>>> @@ -412,7 +412,7 @@ struct octeon_hcd {
>>>>>>>>>> type c;
>>>> \
>>>>>>>>>> while (1) {
>>>> \
>>>>>>>>>> c.u32 = __cvmx_usb_read_csr32(usb, address);
>>>> \
>>>>>>>>>> -if (c.s.field op (value)) {
>>>> \
>>>>>>>>>> +if (c.s.field op(value)) {
>>>> \
>>>>>>>>>
>>>>>>>>> have you read the code before modifying it?
>>>>>>>>> this is not a function.
>>>>>>>>> have you seen how CVMX_WAIT_FOR_FIELD32 is being called?
>>>>>>>>> on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "=="
>>>>>>>>> so when called the macro will be c.s.field == (value).
>>>>>>>>> if your patch is applied then it will become c.s.field ==(value) ..
>>>> will that be correct ?
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> sudip
>>>>>>>>>
>>>>>>>>>> result = 0;
>>>> \
>>>>>>>>>> break;
>>>> \
>>>>>>>>>> } else if (cvmx_get_cycle() > done) {
>>>> \
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: Fix spacing between function name and parentheses
Thank you for your help, I'll study the code and see what I can do
about it. Do you have any suggestions of how to fix this checkpatch
warning?
Nick
On 14-10-11 05:53 AM, Kristofer Hallin wrote:
> Even if you use checkpath you _should_ understand what you are changing.
> The output of checkpatch merely there to help.
>
> In this case you can see that this is a macro just a few lines up in the
> code.
> On 11 Oct 2014 11:46, "Sudip Mukherjee" wrote:
>
>> I agree. But in my opinion checkpatch is here to help us fix style
>> problems , but we should not blindly act on checkpatch warnings.
>>
>> thanks
>> sudip
>>
>> On Sat, Oct 11, 2014 at 1:57 PM, Peter Senna Tschudin
>> wrote:
>>> I think that, in this case, checkpatch.pl contributed:
>>>
>>> $ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c
>>> WARNING: space prohibited between function name and open parenthesis '('
>>> #415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415:
>>> + if (c.s.field op (value)) {
>>\
>>>
>>>
>>> On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian
>> wrote:
>>>> Agreed - that is why I mentioned the patch is neither right nor useful:)
>>>>
>>>> -daveti
>>>>
>>>>
>>>> On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee <
>> sudipm.mukher...@gmail.com> wrote:
>>>>
>>>>> Hi Dave,
>>>>> It will work. But my point of saying that was c.s.field ==(value) is
>>>>> again not according to the style.
>>>>>
>>>>> thanks
>>>>> sudip
>>>>>
>>>>> On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian
>> wrote:
>>>>>> It also works as value is surrounded by (), though I do not think the
>> patch itself is right or useful.
>>>>>>
>>>>>> Dave Tian
>>>>>> dave.jing.t...@gmail.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <
>> sudipm.mukher...@gmail.com> wrote:
>>>>>>
>>>>>>> On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
>>>>>>>> Fixes checkpatch coding style warning about unneeded space
>>>>>>>> between function name an parentheses.
>>>>>>>>
>>>>>>>> Signed-off-by: Nicholas Krause
>>>>>>>> ---
>>>>>>>> Untested
>>>>>>>> drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/staging/octeon-usb/octeon-hcd.c
>> b/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>>> index 5f9db4c..bbeb0cc 100644
>>>>>>>> --- a/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>>> +++ b/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>>> @@ -412,7 +412,7 @@ struct octeon_hcd {
>>>>>>>> type c;
>> \
>>>>>>>> while (1) {
>> \
>>>>>>>> c.u32 = __cvmx_usb_read_csr32(usb, address);
>> \
>>>>>>>> -if (c.s.field op (value)) {
>> \
>>>>>>>> +if (c.s.field op(value)) {
>> \
>>>>>>>
>>>>>>> have you read the code before modifying it?
>>>>>>> this is not a function.
>>>>>>> have you seen how CVMX_WAIT_FOR_FIELD32 is being called?
>>>>>>> on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "=="
>>>>>>> so when called the macro will be c.s.field == (value).
>>>>>>> if your patch is applied then it will become c.s.field ==(value) ..
>> will that be correct ?
>>>>>>>
>>>>>>> thanks
>>>>>>> sudip
>>>>>>>
>>>>>>>> result = 0;
>> \
>>>>>>>> break;
>> \
>>>>>>>> } else if (cvmx_get_cycle() > done) {
>> \
>>>>>>>> --
>>>>>>>> 1.9.1
>>>>>>>>
>>>>>>>>
>>>>>>>> ___
>>>>>>>> Kernelnewbies mailing list
>>>>>>>> Kernelnewbies@kernelnewbies.org
>>>>>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>>>>>
>>>>>>> ___
>>>>>>> Kernelnewbies mailing list
>>>>>>> Kernelnewbies@kernelnewbies.org
>>>>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>>>>
>>>>
>>>>
>>>> ___
>>>> Kernelnewbies mailing list
>>>> Kernelnewbies@kernelnewbies.org
>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>
>>>
>>>
>>> --
>>> Peter
>>
>> ___
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Banned Again
I am getting very annoyed , that I am banned again from my other email at yoc...@gmail.com are people trying to just prevent me from being on the list. Is that your goal now? Cheers Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Help with XfsTests
I am trying to run xfs tests on a partion at /dev/sdc1 but the scripts state that the drive is not at $TEST_DIR and if ' it's on that directory they abort after fsck. Does anybody known how to fix this please. Thanks, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Issues with Community
On 14-09-17 02:59 PM, Sudip Mukherjee wrote: > ___ >>> Kernelnewbies mailing list >>> Kernelnewbies@kernelnewbies.org >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> Sure I will look into linux-next issues later today. >> Nick >> > you mean to say you have not yet seen linux-next?? but i remember seeing > mails from you regarding git and linux-next.. > so this is another example of ignoring advices given to you. > >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > No I meant I will look into working on linux-next not about seeing it, sorry my wording is causing confusion, if it is please let me known so I can help you understand. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
On Wed, Sep 17, 2014 at 2:15 PM, Robert P. J. Day wrote: > On Wed, 17 Sep 2014, Nick Krause wrote: > >> ... like to improve my rep with a tutor or someone who is willing to >> be my router to the community ... > > there is no sane human being that would offer to be a tutor or > mentor (a request you've made before) or "router" to someone who > absolutely refuses to listen to the advice people give him. > > you have absolutely no idea what mentoring involves, do you, nick? > people offer to become mentors because they find up and coming folks > who appear to be bright, ambitious and teachable, not irredeemably > thick. > > this *entire* *mailing* *list* has been trying to tutor or mentor > you for the last two months, and it has been a colossal waste of time. > where do you get the nerve to now ask for *personal* assistance, given > that everyone knows you simply ignore whatever anyone tells you? > > can we please, fer chrissake, just vote on a ban to get rid of nick > and cut the nonsense on this mailing list by 90%? please? > > rday > > -- > > > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > ==== > I am leaving for now and going to learn more about the kernel and come back with some questions later. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
e stranger on the internet is going to be your tutor? Unless you belong to some minority, you shouldn't be waiting for a tutor to take your hand and guide you... that's probably not going to happen. Apply the advice that's been already given to you, e.g. read the old mails and write each advice down. Until that, *please* lurk moar. On Wed, Sep 17, 2014 at 2:01 PM, Philipp Muhoray wrote: > > Am 2014-09-17 19:47, schrieb Nick Krause: >> On Wed, Sep 17, 2014 at 1:13 PM, Bruno Guedes Souto >> wrote: >>> This was a great discussion, until you guys started feeding the troll again. >>> >>> Can we just stop feeding the troll? He will prob go way... >>> >>> If every *single* time that Nick posts something you reply to him it will >>> only >>> lead to more replies from him saying he will get better, understand what he >>> is >>> doing and that he wants to improve his rep with the community. That's his >>> standard speech. >>> >>> BGS >>> >>> >>> ___ >>> Kernelnewbies mailing list >>> Kernelnewbies@kernelnewbies.org >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbe stranger on the >>> internet is going to be your tutor? Unless you belong to some minority, you shouldn't be waiting for a tutor to take your hand and guide you... that's probably not going to happen. Apply the advice that's been already given to you, e.g. read the old mails and write each advice down. Until that, *please* lurk moar. ies >> Can I stop being called a troll. I am trying to learn here and improve >> my rep and understanding of >> the kernel. I would like to help but with this negative light around >> me it is much more difficult and >> hard to do. I understand the problems I have caused now and would like >> to improve my rep with >> a tutor or someone who is willing to be my router to the community >> until I improve enough to a >> member of the community on my own. >> Thanks Nick >> >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > Why do you think that some stranger on the internet is going to be your > tutor? Unless you belong to some minority, you shouldn't be waiting for > a tutor to take your hand and guide you... that's probably not going to > happen. Apply the advice that's been already given to you, e.g. read the > old mails and write each advice down. Until that, *please* lurk moar. > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies That's what I plan to do now and ask many questions. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
On Wed, Sep 17, 2014 at 1:13 PM, Bruno Guedes Souto wrote: > This was a great discussion, until you guys started feeding the troll again. > > Can we just stop feeding the troll? He will prob go way... > > If every *single* time that Nick posts something you reply to him it will only > lead to more replies from him saying he will get better, understand what he is > doing and that he wants to improve his rep with the community. That's his > standard speech. > > BGS > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Can I stop being called a troll. I am trying to learn here and improve my rep and understanding of the kernel. I would like to help but with this negative light around me it is much more difficult and hard to do. I understand the problems I have caused now and would like to improve my rep with a tutor or someone who is willing to be my router to the community until I improve enough to a member of the community on my own. Thanks Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Issues with Community
On Wed, Sep 17, 2014 at 9:13 AM, Rik van Riel wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 09/16/2014 07:22 PM, nick wrote: >> After numerous tries at good patches and still failing , I am >> listening to what you guys stated about my patches check it >> applies, grammar and build checks. I am still unable to get a good >> patch and would really appreciate it if someone walks me through >> one good patch as I will learn this will a tutor and the tutor can >> help be my router to the community > > There are a lot of useful things to do in the Linux kernel community > besides writing patches. > > One of the useful things you could do is simply run linux-next on your > system, and update whenever new linux-next code comes out. If it breaks > (which it sometimes does), you can write a bug report, and learn from > the resulting email thread what caused the problem. > > Debugging is a much better way to learn development than developing > new patches from scratch "just because"... > > - -- > All rights reversed. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJUGYkCAAoJEM553pKExN6D6ikH/A2iC8wOm1Xa0rpna+i9cCyu > d3tZof+EbMLezsQjNDXHwJgm7bjsKHT55WT68snliugFueWfkX7c8S48wV2bNso6 > iwObDGCt3iXnuNqWrZ4cjJg4Lk3vOWvs3D1FkCEBlhM8lafJZdaaQfXNVLkOAZyt > sg9rypTTeV8e1udp/O2UTNP9jwEasLqU3aGXj5AuTUGI77NiquUDn1fwlTwcregr > nkwv5iCoJuBifm8+GcHHReBzhWX/Ab4d8H+wNGsTHqhlDR3iNyaodMvlHLZcayry > gkZf3+VcZjR9XClBY5yLeNHmRcYeKFm80XeybF3Ih+zxluB5H2jEOKIp9/MbY88= > =S6vR > -END PGP SIGNATURE- > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Sure I will look into linux-next issues later today. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
On Wed, Sep 17, 2014 at 10:39 AM, wrote: > On Wed, 17 Sep 2014 08:02:01 -0400, nick said: >> it off , if not I would like to known exactly where I am wrong so I can >> learn. > > Somebody wake me up when he actually *means* that. > Valdis, I understand that was what he stated I was looking into how to write a correct patch not remove needed error messages. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
On 14-09-17 08:17 AM, Kai Bojens wrote: > On 17-09-14 08:09:36, nick wrote: > > [Again quoting everything] > > Please read and understand this: > > -> http://en.wikipedia.org/wiki/Posting_style#How_much_to_trim > > Your replies are unreadable to me as I don't intend to scroll down > several pages just to read the one line you added as an answer. If > you are seriously interested in any help (I for one doubt this…) you > should start writing in a more readable way. > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > I sent out my last email fine. Your thinking of another email and yes I really would like some help as if I learn more I will be able to a good kernel member with a tutor or some advice. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
> Because in general we don't use asserts in the kernel. I'm sure I've used > 10,000s of asserts in user space over the decades. Zero in the kernel. > > Specifically, in user space when writing code we can put asserts throughout > the code that will cause an immediate code explosion if unexpected things > happen. In the kernel, the better choice is printing an error message then > have the code do it's best to handle it. > > That still begs the question of why it happened in the first place. As long > as the event itself us unexpected (ie. not routine) then the error message > should remain. Re-read the sample commit message I wrote. The first thing I > said is the "condition is well understood". Never remove an error message > unless you can explain with clarity why the "error" is happening. Obviously > in that case you should be replacing the error message with a comment that > explains the condition. > > Greg > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. Thanks Greg, I will look into in more carefully later. In addition thanks to all the others for the patience and help. I understand that this is not normal in the kernel community and would like to really thank everyone for the patience and support. I want to help out and as I am finding out the coding is not the issue it's my issues with the community which I hope we can fix in order for me to help the kernel community. In addition I do find the kernel interesting and really like working with it, just having issues with understanding how to write patches. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
On 14-09-17 08:17 AM, Chris Lee wrote: >> >> Rday, >> I meant I didn't understand the code not the effect to write good solid >> patches and learn it. >> Please read my messages more carefully. >> Nick >> >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > Terrible reason to submit a patch. If you dont understand the code snippet, > you should not be submitting patch's against them. You need to fully > understand the code inside and out before you even consider fixing it. > > Chris > Thanks Chris, I agree with you now. I didn't mean about check patch for your information but on other parts. Thanks Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
On 14-09-17 08:05 AM, Greg Freemyer wrote: > > > On September 17, 2014 7:53:24 AM EDT, nick wrote: >> >> >> On 14-09-17 07:51 AM, Sudip Mukherjee wrote: >>> On Wed, Sep 17, 2014 at 5:08 PM, nick wrote: >>>> >>>> >>>> On 14-09-17 07:20 AM, Robert P. J. Day wrote: >>> >>>>> anyway, it's time for coffee. >>>>> >>>>> rday >>>>> >>>> Rday and others, >>>> That's not what I wanted I was trying to improve my rep after >> getting banned from vger.org and now it seems >>>> I can't even get a patch right. In addition I was trying to do check >> patch because it was easier for me >>>> due to not understanding some parts of the code. >>>> Nick >>>> >>> >>> try to understand the code first. if you do not understand the code >>> how do you know that your patch will not break any part of the logic >> . >>> ok , by adding blank lines you will not break the logic. >>> but yesterday in your other patch you removed an error message . may >> i >>> ask why did you think that error message is not required ? >>> >>> thanks >>> sudip >>> >>>> ___ >>>> Kernelnewbies mailing list >>>> Kernelnewbies@kernelnewbies.org >>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> I thought that the return statement of NULL to a caller was enough. >> Nick > > Uh... > > I don't know that chunk of code, but error messages that go to the kernel log > exist for a specific reason. Taking them out requires a specific reason. > > Ie. This would make a good commit message "At this point the condition is > well understood and the code that handles it is well tested and has been > stable for 3 years, thus removing the error message." > > Greg > Thanks Greg Again, This is what I meant with my patch, why have a unneeded error message if the code is already tested and only uses the return value in that function. Cheers Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
On 14-09-17 08:00 AM, Robert P. J. Day wrote: > On Wed, 17 Sep 2014, Greg Freemyer wrote: > >> >> >> On September 17, 2014 7:20:42 AM EDT, "Robert P. J. Day" >> wrote: >> >>> >>> and, as we've all seen, nick's other flaw is that, quite simply, >>> he's selfish and greedy. his entire obsession is with the output of >>> checkpatch, which means he wants to grab all the trivial cleanup (the >>> low-hanging fruit, as it were) for himself, and not leave any for >>> others. rather than take the time to understand the code, nick wants >>> checkpatch to do all the work for him. in the end, nick doesn't want >>> to do any work or understand how the kernel actually works -- he just >>> wants patches, and he wants them as quickly and cheaply as possible. >> >> Nick and his patches may have plenty of flaws, but I think it is a >> bit crazy to call his effort to get his first patch into the kernel >> greedy. > > i was actually referring to nick's more recent posting where he > vowed to use his patch as the template to start cleaning up all of > drivers/staging/. i thought i was fairly clear that there is nothing > wrong with *starting* with stylistic cleanup, but nick made it quite > clear he planned on doing this all over drivers/staging. *that* is > what i was referring to. > > rday > Rday, Your reading that wrong what I mean is to use the format as a template for patches I am going to send out, not clean up drivers/staging all of it a least. I was stating I wanted to only clean up a bit there in order to get comfortable with sending out patches. Sorry about the miswritten message, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
On 14-09-17 07:56 AM, Greg Freemyer wrote: > > > On September 17, 2014 7:20:42 AM EDT, "Robert P. J. Day" > wrote: > >> >> and, as we've all seen, nick's other flaw is that, quite simply, >> he's selfish and greedy. his entire obsession is with the output of >> checkpatch, which means he wants to grab all the trivial cleanup (the >> low-hanging fruit, as it were) for himself, and not leave any for >> others. rather than take the time to understand the code, nick wants >> checkpatch to do all the work for him. in the end, nick doesn't want >> to do any work or understand how the kernel actually works -- he just >> wants patches, and he wants them as quickly and cheaply as possible. > > Nick and his patches may have plenty of flaws, but I think it is a bit crazy > to call his effort to get his first patch into the kernel greedy. > >>From what little I know he originally started trying to make functional code >>changes around various fixme's in the code. Not surprisingly, that took more >>overall kernel knowledge than he had. If fixme's were trivial, they would >>have been fixed in the first place, not a comment. > > If Greg KH welcomes code style patches in the staging code as a way for > newbies to learn the workflow, then that is a great thing. > > Greg (not kh) > Thanks Greg, That is exactly what happened with my issues, I started on things with more then I could handle and due to that and not listening was banned. If someone with re look at my patch and tell if it's OK or not, if it's good please sent it off , if not I would like to known exactly where I am wrong so I can learn. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
On 14-09-17 07:53 AM, Robert P. J. Day wrote: > > what did i say? what did i just say? i wrote: > > On Wed, 17 Sep 2014, nick wrote: >> On 14-09-17 07:20 AM, Robert P. J. Day wrote: >>> >>> and, as we've all seen, nick's other flaw is that, quite simply, >>> he's selfish and greedy. his entire obsession is with the output >>> of checkpatch, which means he wants to grab all the trivial >>> cleanup (the low-hanging fruit, as it were) for himself, and not >>> leave any for others. rather than take the time to understand the > ^^^ >>> code, nick wants checkpatch to do all the work for him. in the >>> end, nick doesn't want to do any work or understand how the kernel >>> actually works -- he just wants patches, and he wants them as >>> quickly and cheaply as possible. > > to which nick responds (unbelievably, and confirming what i had > just written): > >> That's not what I wanted I was trying to improve my rep after >> getting banned from vger.org and now it seems I can't even get a >> patch right. In addition I was trying to do check patch because it >> was easier for me due to not understanding some parts of the code. > ^ > > i rarely have my speculation confirmed so rapidly and completely. > > rday > Rday, I meant I didn't understand the code not the effect to write good solid patches and learn it. Please read my messages more carefully. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
On 14-09-17 07:51 AM, Sudip Mukherjee wrote: > On Wed, Sep 17, 2014 at 5:08 PM, nick wrote: >> >> >> On 14-09-17 07:20 AM, Robert P. J. Day wrote: > >>> anyway, it's time for coffee. >>> >>> rday >>> >> Rday and others, >> That's not what I wanted I was trying to improve my rep after getting banned >> from vger.org and now it seems >> I can't even get a patch right. In addition I was trying to do check patch >> because it was easier for me >> due to not understanding some parts of the code. >> Nick >> > > try to understand the code first. if you do not understand the code > how do you know that your patch will not break any part of the logic . > ok , by adding blank lines you will not break the logic. > but yesterday in your other patch you removed an error message . may i > ask why did you think that error message is not required ? > > thanks > sudip > >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies I thought that the return statement of NULL to a caller was enough. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
On 14-09-17 07:20 AM, Robert P. J. Day wrote: > On Tue, 16 Sep 2014, Greg KH wrote: > >> On Tue, Sep 16, 2014 at 11:42:18PM -0400, valdis.kletni...@vt.edu wrote: >>> (And this sort of analysis is exactly *why* people need to apply their >>> brains >>> when looking at checkpatch output) >> >> No one has ever said that they shouldn't. >> >> Remember, I know _lots_ of kernel developers who started with just >> "checkpatch cleanups on staging drivers" and they moved on to much >> "higher" roles in the kernel developer ecosystem (jobs, maintainers >> of subsystems, keynote talks at conferences, etc.) >> >> Don't "po po" it as something that shouldn't be a valid place to >> start, it is, and is why I do the work to review all of the many >> thousands of staging patches every release cycle. >> >> No one is forcing you to write those patches, or read / review them, >> so don't discourage others to provide them either please. I most >> certainly do not. > > so while i'm waxing philosophical, some other thoughts that occurred > to me that reflect on how i got started, and ways to become a more and > more useful contributor to the kernel for newbies (and i'm willing to > be corrected on any of this). > > first, stop with the blind running of checkpatch unless you're > willing to take the results and examine the *context* in which they > occur. that file needs blank lines? ok, does it reside in a directory > of related files that could *also* use some blank lines? then do them > *all* -- don't waste peoples' time fixing one file at a time. if you > can do the same stylistic cleanup on an entire subsystem, go for it, > and don't clutter up the git log with numerous trivial commits. > > *but* ... don't try to sneak functional changes in there at the same > time. if it's a style cleanup, then it's a *style* cleanup. one thing > at a time. but there are other places you can make a name. > > first, read the Documentation/ directory -- there's lots of content > there, and quite a bit of it is out of date or just plain obsolete. > and if you want people to love you, improve the documentation. but, > see, that's going to take some work. and that's because it requires > you to read the documentation, then go off and examine the > corresponding code to see if it still matches. and why is this good? > > because while updating the Documentation/ content is safe and can't > break anything, the side effect is that you *learn* about that > particular subsystem, you get some nifty patches into the kernel, and > you make lots and lots of friends. > > another place to get cheap patches is to repair any kernel-doc > warnings, and there are *always* plenty of those. again, fixing > kernel-doc content shouldn't break anything, it should be easy > patching, and it normally requires you to at least examine the code to > make sure you're fixing it properly. so, you get patches into the > kernel, and you learn a bit more about some code. win-win. > > last point here regarding something gregkh wrote -- yes, it's fine > to *start* with simple stylistic cleanup, especially if checkpatch > does all the work for you. but remember, that's low-hanging fruit, and > you shouldn't be greedy and try and do all of it. if stylistic cleanup > is a way for beginners to get their first patches into the kernel, > then don't be a pig and try to do it all -- leave some for others to > cut their teeth on. and what is the point of all this? > > quite simply, this is also why nick krause will never be a useful > member of the kernel community. i suggested a while back that nick > could start with improving the documentation, for all the reasons i > mentioned above. his response was that he didn't know enough to do > that, which is an astonishing thing to admit. if you don't know enough > to improve the basic documentation, you have no right to be mucking > around in the code. > > and, as we've all seen, nick's other flaw is that, quite simply, > he's selfish and greedy. his entire obsession is with the output of > checkpatch, which means he wants to grab all the trivial cleanup (the > low-hanging fruit, as it were) for himself, and not leave any for > others. rather than take the time to understand the code, nick wants > checkpatch to do all the work for him. in the end, nick doesn't want > to do any work or understand how the kernel actually works -- he just > wants patches, and he wants them as quickly and cheaply as possible. > > anyway, it's time for coffee. > > rday > Rday and others, That's not what I wanted I was trying to improve my rep after getting banned from vger.org and now it seems I can't even get a patch right. In addition I was trying to do check patch because it was easier for me due to not understanding some parts of the code. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging wlan-ng: Add missing blank lines after declarations
On 14-09-16 10:41 PM, Nicholas Krause wrote:
> Fixing trivial checkpatch warnings about missing blank lines after
> declarations.
>
> Signed-off-by: Nicholas Krause
> ---
> drivers/staging/wlan-ng/hfa384x.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/staging/wlan-ng/hfa384x.h
> b/drivers/staging/wlan-ng/hfa384x.h
> index 1f2c78c..20d146b 100644
> --- a/drivers/staging/wlan-ng/hfa384x.h
> +++ b/drivers/staging/wlan-ng/hfa384x.h
> @@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid, void
> *buf, u16 len);
> static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
> {
> int result = 0;
> +
> result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
> if (result == 0)
> *((u16 *) val) = le16_to_cpu(*((u16 *) val));
> @@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t
> *hw, u16 rid, void *val)
> static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16 val)
> {
> u16 value = cpu_to_le16(val);
> +
> return hfa384x_drvr_setconfig(hw, rid, &value, sizeof(value));
> }
>
> @@ -1402,6 +1404,7 @@ static inline int
> hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
> {
> u16 value = cpu_to_le16(val);
> +
> return hfa384x_drvr_setconfig_async(hw, rid, &value, sizeof(value),
> NULL, NULL);
> }
>
Greg and others,
Thanks to Amit for checking my grammar firstly. I would like to known before I
start cleaning drivers/staging/ and it's subdirectories if this patch is good
and valid so I can use it as a template for me to look at when I send out
my other patches.
Thanks and Am So Thankful for all the Chances Here,
Nick
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Issues with Community
After numerous tries at good patches and still failing , I am listening to what you guys stated about my patches check it applies, grammar and build checks. I am still unable to get a good patch and would really appreciate it if someone walks me through one good patch as I will learn this will a tutor and the tutor can help be my router to the community for now in order to start helping me learn how to be involved correctly and follow the community rules. I am willing to work on my patches if someone is willing to do this for me and help me improve my taste in the communities mouth. Thanks, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging wlan-ng: Add missing blank lines after declarations
On 14-09-16 05:58 PM, Nicholas Krause wrote:
> Fixing trivial checkpatch warnings about missing blanks lines after
> declarations.
>
> Signed-off-by: Nicholas Krause
> ---
> drivers/staging/wlan-ng/hfa384x.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/staging/wlan-ng/hfa384x.h
> b/drivers/staging/wlan-ng/hfa384x.h
> index 1f2c78c..20d146b 100644
> --- a/drivers/staging/wlan-ng/hfa384x.h
> +++ b/drivers/staging/wlan-ng/hfa384x.h
> @@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid, void
> *buf, u16 len);
> static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
> {
> int result = 0;
> +
> result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
> if (result == 0)
> *((u16 *) val) = le16_to_cpu(*((u16 *) val));
> @@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t
> *hw, u16 rid, void *val)
> static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16 val)
> {
> u16 value = cpu_to_le16(val);
> +
> return hfa384x_drvr_setconfig(hw, rid, &value, sizeof(value));
> }
>
> @@ -1402,6 +1404,7 @@ static inline int
> hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
> {
> u16 value = cpu_to_le16(val);
> +
> return hfa384x_drvr_setconfig_async(hw, rid, &value, sizeof(value),
> NULL, NULL);
> }
>
I checked my grammar. I am assuming I am still wrong through.
Nick
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging wlan-ng: Add missing a blank line after declarations
On 14-09-16 05:20 PM, Nicholas Krause wrote:
> Fixing trivial checkpatch warnings about missing line after declarations
>
> Signed-off-by: Nicholas Krause
> ---
> drivers/staging/wlan-ng/hfa384x.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/staging/wlan-ng/hfa384x.h
> b/drivers/staging/wlan-ng/hfa384x.h
> index 1f2c78c..20d146b 100644
> --- a/drivers/staging/wlan-ng/hfa384x.h
> +++ b/drivers/staging/wlan-ng/hfa384x.h
> @@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid, void
> *buf, u16 len);
> static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
> {
> int result = 0;
> +
> result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
> if (result == 0)
> *((u16 *) val) = le16_to_cpu(*((u16 *) val));
> @@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t
> *hw, u16 rid, void *val)
> static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16 val)
> {
> u16 value = cpu_to_le16(val);
> +
> return hfa384x_drvr_setconfig(hw, rid, &value, sizeof(value));
> }
>
> @@ -1402,6 +1404,7 @@ static inline int
> hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
> {
> u16 value = cpu_to_le16(val);
> +
> return hfa384x_drvr_setconfig_async(hw, rid, &value, sizeof(value),
> NULL, NULL);
> }
>
I checked this patch and there seems to be issues that any of you have stated
before after not applying or grammar e.t.c. If there are any other errors I am
missing please let me known.
Nick
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, Sep 16, 2014 at 1:39 PM, wrote: > On Tue, 16 Sep 2014 13:28:06 -0400, Rik van Riel said: >> -BEGIN PGP SIGNED MESSAGE- > >> On 09/16/2014 01:12 PM, Nick Krause wrote: >> >> > I am going to resend my patch and see if it's good and if not I am >> > going to leave for a while. >> >> You may want to consider fixing them, by applying the advice >> provided by many people, before resending them. > > That's just crazy talk. > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > I am fixing them first and them sending them out. I am going to listen now and only do them correctly. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, Sep 16, 2014 at 12:57 PM, Sudip Mukherjee wrote: > On 9/16/14, Nick Krause wrote: >> On Tue, Sep 16, 2014 at 10:19 AM, wrote: >>> On Tue, 16 Sep 2014 08:44:27 -0400, nick said: >>> >>>> I am attaching two check patch patches I wrote in the last few days as I >>>> am unable to get a reply >>>> from the maintainers. Would someone please send them off for me. >>> >>> "I am attaching". Fail 3 words in. >>> >>> That's why you aren't getting a reply from the maintainers. They don't >>> bother >>> reading patches they know will probably *never* be correct. >>> >>> And yes, at least one of the two patches is incorrect. >>> >>>>> Thanks for the Help, I really do appreciate it and I do understand how >>>>> much I have screwed up. My concern now is >>>>> now to make it right. >>> >>> You don't make it right by posting more wrong patches. Now do us >>> all a favor and *stop* being either an idiot, or a troll, or whatever >>> your problem is. We have *zero* desire to see *any* more patches from >>> somebody who is either unable or unwilling to post a *single* correct >>> patch after *two months* of trying. >>> >>> So please do us a favor and go piss off some other open source project. >>> >>> THE KERNEL DOES NOT WANT YOUR BULLSHIT. >>> >>> >>> >> I am going to attach it again and I understand Valdis. I am going to >> talk to Sudip about reading and checking >> my patches first. >> Nick >> > > plzzz .. NO ... > today i checked your patches just to take a break from what i was doing.. > and besides , i am also a newbie , i also make mistakes when > submitting patches, but i try to learn from my mistakes and see to it > that they are never repeated. > apart from the numerous advises you got from the LKML , i think just > yesterday Robert P. J. Day has pointed out something, day before > yesterday Valdis , before that ( sorry i lost track) ... and you have > not cared to listen to any of that .. > > > >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> I am going to resend my patch and see if it's good and if not I am going to leave for a while. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, Sep 16, 2014 at 10:19 AM, wrote: > On Tue, 16 Sep 2014 08:44:27 -0400, nick said: > >> I am attaching two check patch patches I wrote in the last few days as I am >> unable to get a reply >> from the maintainers. Would someone please send them off for me. > > "I am attaching". Fail 3 words in. > > That's why you aren't getting a reply from the maintainers. They don't bother > reading patches they know will probably *never* be correct. > > And yes, at least one of the two patches is incorrect. > >>> Thanks for the Help, I really do appreciate it and I do understand how much >>> I have screwed up. My concern now is >>> now to make it right. > > You don't make it right by posting more wrong patches. Now do us > all a favor and *stop* being either an idiot, or a troll, or whatever > your problem is. We have *zero* desire to see *any* more patches from > somebody who is either unable or unwilling to post a *single* correct > patch after *two months* of trying. > > So please do us a favor and go piss off some other open source project. > > THE KERNEL DOES NOT WANT YOUR BULLSHIT. > > > I am going to attach it again and I understand Valdis. I am going to talk to Sudip about reading and checking my patches first. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On 14-09-16 09:06 AM, Sudip Mukherjee wrote:
> On Tue, Sep 16, 2014 at 08:44:27AM -0400, nick wrote:
>> I am attaching two check patch patches I wrote in the last few days as I am
>> unable to get a reply
>> from the maintainers. Would someone please send them off for me.
>> Thanks,
>> Nick
>
>> >From 7bf4229fa2f9c4fcf3243bc738c74bfdc58a6594 Mon Sep 17 00:00:00 2001
>> From: Nicholas Krause
>> Date: Sat, 13 Sep 2014 11:53:24 -0400
>> Subject: [PATCH] staging wlan-ng: Add missing a blank line after declarations
>>
>> Fixing trivial checkpatch warnings about missing line after
>> declarations.
>>
>> Signed-off-by: Nicholas Krause
>> ---
>> Tested by compilation only.
>> drivers/staging/wlan-ng/hfa384x.h | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/staging/wlan-ng/hfa384x.h
>> b/drivers/staging/wlan-ng/hfa384x.h
>> index 1f2c78c..20d146b 100644
>> --- a/drivers/staging/wlan-ng/hfa384x.h
>> +++ b/drivers/staging/wlan-ng/hfa384x.h
>> @@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid,
>> void *buf, u16 len);
>> static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void
>> *val)
>> {
>> int result = 0;
>> +
>> result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
>> if (result == 0)
>> *((u16 *) val) = le16_to_cpu(*((u16 *) val));
>> @@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t
>> *hw, u16 rid, void *val)
>> static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16 val)
>> {
>> u16 value = cpu_to_le16(val);
>> +
>> return hfa384x_drvr_setconfig(hw, rid, &value, sizeof(value));
>> }
>> @@ -1402,6 +1404,7 @@ static inline int
>> hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
>> {
>> u16 value = cpu_to_le16(val);
>> +
>> return hfa384x_drvr_setconfig_async(hw, rid, &value, sizeof(value),
>> NULL, NULL);
>> }
>> 1.9.1
>>
>
>> >From 5eb3de22f0760ece1e838d48c8dd9148b4331cdc Mon Sep 17 00:00:00 2001
>> From: Nicholas Krause
>> Date: Mon, 15 Sep 2014 17:07:24 -0400
>> Subject: [PATCH] staging netlogic: Fix checkpatch errors in xlr_net.c
>>
>> This removes the checkpatch errors related to a needed line below
>> declaration of a struct and another about a non nessary printk
>> message about a NULL allocated skb due to the function returning
>> NULL to the caller of the function and the printk no longer being'
>> used or needed by any callers.
>>
>
> spelling mistakes
>
>> Signed-off-by: Nicholas Krause
>> ---
>> drivers/staging/netlogic/xlr_net.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/staging/netlogic/xlr_net.c
>> b/drivers/staging/netlogic/xlr_net.c
>> index 9bf407d..28a42831 100644
>> --- a/drivers/staging/netlogic/xlr_net.c
>> +++ b/drivers/staging/netlogic/xlr_net.c
>> @@ -142,10 +142,8 @@ static inline struct sk_buff *xlr_alloc_skb(void)
>>
>> /* skb->data is cache aligned */
>> skb = alloc_skb(XLR_RX_BUF_SIZE, GFP_ATOMIC);
>> -if (!skb) {
>> -pr_err("SKB allocation failed\n");
>
> why the error message was removed ?
>
>
>> +if (!skb)
>> return NULL;
>> -}
>> mac_put_skb_back_ptr(skb);
>> return skb;
>> }
>> @@ -1104,6 +1102,7 @@ err_gmac:
>> static int xlr_net_remove(struct platform_device *pdev)
>> {
>> struct xlr_net_priv *priv = platform_get_drvdata(pdev);
>> +
>> unregister_netdev(priv->ndev);
>> mdiobus_unregister(priv->mii_bus);
>> mdiobus_free(priv->mii_bus);
>> --
>> 1.9.1
>>
>
> ohhh .. yeah .. and both the patch failed when i tried to apply them to
> next-20140916
>
>
> why are we wasting our time for your patches , which are bound to have some
> problem
>
> thanks
> sudip
>
>
>> ___
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
I tried these on Greg's tree of staging-next and they worked for me.
Nick
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On 14-09-16 09:21 AM, Sudip Mukherjee wrote:
> On Tue, Sep 16, 2014 at 6:41 PM, nick wrote:
>>
>>
>> On 14-09-16 09:06 AM, Sudip Mukherjee wrote:
>>> On Tue, Sep 16, 2014 at 08:44:27AM -0400, nick wrote:
>>>> I am attaching two check patch patches I wrote in the last few days as I
>>>> am unable to get a reply
>>>> from the maintainers. Would someone please send them off for me.
>>>> Thanks,
>>>> Nick
>>>
>>>> >From 7bf4229fa2f9c4fcf3243bc738c74bfdc58a6594 Mon Sep 17 00:00:00 2001
>>>> From: Nicholas Krause
>>>> Date: Sat, 13 Sep 2014 11:53:24 -0400
>>>> Subject: [PATCH] staging wlan-ng: Add missing a blank line after
>>>> declarations
>>>>
>>>> Fixing trivial checkpatch warnings about missing line after
>>>> declarations.
>>>>
>>>> Signed-off-by: Nicholas Krause
>>>> ---
>>>> Tested by compilation only.
>>>> drivers/staging/wlan-ng/hfa384x.h | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/drivers/staging/wlan-ng/hfa384x.h
>>>> b/drivers/staging/wlan-ng/hfa384x.h
>>>> index 1f2c78c..20d146b 100644
>>>> --- a/drivers/staging/wlan-ng/hfa384x.h
>>>> +++ b/drivers/staging/wlan-ng/hfa384x.h
>>>> @@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid,
>>>> void *buf, u16 len);
>>>> static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void
>>>> *val)
>>>> {
>>>> int result = 0;
>>>> +
>>>> result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
>>>> if (result == 0)
>>>> *((u16 *) val) = le16_to_cpu(*((u16 *) val));
>>>> @@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t
>>>> *hw, u16 rid, void *val)
>>>> static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16
>>>> val)
>>>> {
>>>> u16 value = cpu_to_le16(val);
>>>> +
>>>> return hfa384x_drvr_setconfig(hw, rid, &value, sizeof(value));
>>>> }
>>>> @@ -1402,6 +1404,7 @@ static inline int
>>>> hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
>>>> {
>>>> u16 value = cpu_to_le16(val);
>>>> +
>>>> return hfa384x_drvr_setconfig_async(hw, rid, &value, sizeof(value),
>>>> NULL, NULL);
>>>> }
>>>> 1.9.1
>>>>
>>>
>>>> >From 5eb3de22f0760ece1e838d48c8dd9148b4331cdc Mon Sep 17 00:00:00 2001
>>>> From: Nicholas Krause
>>>> Date: Mon, 15 Sep 2014 17:07:24 -0400
>>>> Subject: [PATCH] staging netlogic: Fix checkpatch errors in xlr_net.c
>>>>
>>>> This removes the checkpatch errors related to a needed line below
>>>> declaration of a struct and another about a non nessary printk
>>>> message about a NULL allocated skb due to the function returning
>>>> NULL to the caller of the function and the printk no longer being'
>>>> used or needed by any callers.
>>>>
>>>
>>> spelling mistakes
>>>
>>>> Signed-off-by: Nicholas Krause
>>>> ---
>>>> drivers/staging/netlogic/xlr_net.c | 5 ++---
>>>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/staging/netlogic/xlr_net.c
>>>> b/drivers/staging/netlogic/xlr_net.c
>>>> index 9bf407d..28a42831 100644
>>>> --- a/drivers/staging/netlogic/xlr_net.c
>>>> +++ b/drivers/staging/netlogic/xlr_net.c
>>>> @@ -142,10 +142,8 @@ static inline struct sk_buff *xlr_alloc_skb(void)
>>>>
>>>> /* skb->data is cache aligned */
>>>> skb = alloc_skb(XLR_RX_BUF_SIZE, GFP_ATOMIC);
>>>> -if (!skb) {
>>>> -pr_err("SKB allocation failed\n");
>>>
>>> why the error message was removed ?
>>>
>>>
>>>> +if (!skb)
>>>> return NULL;
>>>> -}
>>>> mac_put_skb_back_ptr(skb);
>>>> return skb;
>>>> }
>>>> @@ -1104,6 +1102,7 @@ err_gmac:
>>>> static int xlr_net_remove(struct platform_device *pdev)
>>>> {
>>>> str
Checkpatch Patches
I am attaching two check patch patches I wrote in the last few days as I am
unable to get a reply
from the maintainers. Would someone please send them off for me.
Thanks,
Nick
>From 7bf4229fa2f9c4fcf3243bc738c74bfdc58a6594 Mon Sep 17 00:00:00 2001
From: Nicholas Krause
Date: Sat, 13 Sep 2014 11:53:24 -0400
Subject: [PATCH] staging wlan-ng: Add missing a blank line after declarations
Fixing trivial checkpatch warnings about missing line after
declarations.
Signed-off-by: Nicholas Krause
---
Tested by compilation only.
drivers/staging/wlan-ng/hfa384x.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/wlan-ng/hfa384x.h b/drivers/staging/wlan-ng/hfa384x.h
index 1f2c78c..20d146b 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid, void *buf, u16 len);
static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
{
int result = 0;
+
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
*((u16 *) val) = le16_to_cpu(*((u16 *) val));
@@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig(hw, rid, &value, sizeof(value));
}
@@ -1402,6 +1404,7 @@ static inline int
hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig_async(hw, rid, &value, sizeof(value),
NULL, NULL);
}
1.9.1
>From 5eb3de22f0760ece1e838d48c8dd9148b4331cdc Mon Sep 17 00:00:00 2001
From: Nicholas Krause
Date: Mon, 15 Sep 2014 17:07:24 -0400
Subject: [PATCH] staging netlogic: Fix checkpatch errors in xlr_net.c
This removes the checkpatch errors related to a needed line below
declaration of a struct and another about a non nessary printk
message about a NULL allocated skb due to the function returning
NULL to the caller of the function and the printk no longer being'
used or needed by any callers.
Signed-off-by: Nicholas Krause
---
drivers/staging/netlogic/xlr_net.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/netlogic/xlr_net.c b/drivers/staging/netlogic/xlr_net.c
index 9bf407d..28a42831 100644
--- a/drivers/staging/netlogic/xlr_net.c
+++ b/drivers/staging/netlogic/xlr_net.c
@@ -142,10 +142,8 @@ static inline struct sk_buff *xlr_alloc_skb(void)
/* skb->data is cache aligned */
skb = alloc_skb(XLR_RX_BUF_SIZE, GFP_ATOMIC);
- if (!skb) {
- pr_err("SKB allocation failed\n");
+ if (!skb)
return NULL;
- }
mac_put_skb_back_ptr(skb);
return skb;
}
@@ -1104,6 +1102,7 @@ err_gmac:
static int xlr_net_remove(struct platform_device *pdev)
{
struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+
unregister_netdev(priv->ndev);
mdiobus_unregister(priv->mii_bus);
mdiobus_free(priv->mii_bus);
--
1.9.1
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On 14-09-16 08:47 AM, Kristofer Hallin wrote: > I wouldn't touch those with a ten foot pole. > On 16 Sep 2014 14:46, "nick" wrote: > >> I am attaching two check patch patches I wrote in the last few days as I >> am unable to get a reply >> from the maintainers. Would someone please send them off for me. >> Thanks, >> Nick >> >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >> > Kristofer, I would appreciate if you look at them and see if there any good. I understand based on my other patches so assumptions but it would be nice if you only too a look for me. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Improve my Rep
On Mon, Sep 15, 2014 at 11:16 AM, Anuz Pratap Singh Tomar wrote: > > > On Mon, Sep 15, 2014 at 3:38 PM, Nick Krause wrote: >> >> After issues with the community I am wondering how to improve my rep >> and help out more. >> I will start out with check patch but if there is other work please >> let me known :). >> > Seriously, you are beyond help. > A lot of people have tried to answer your mails, correct your patches and > give you correct advice, but you choose to ignore all of that. > This behaviour qualifies as either a) Trolling or b) you need medical > help(as a lot of people pointed out on LKML). > So please seriously stop, I am not sure what are you trying to achieve by > posting here, but it is just noise and annoyance to everyone. > >> >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > > -- > Thank you > Warm Regards > Anuz I am sure I can help. Seems I need to be more careful with my patches. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Improve my Rep
After issues with the community I am wondering how to improve my rep and help out more. I will start out with check patch but if there is other work please let me known :). ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
