Re: [PATCH] usb: Fix switch statement in ohci-tmio.c
On Thu, Aug 14, 2014 at 2:05 PM, Nicholas Krause <xerofoify@gmail.com> wrote:
I am fixing the bug on at the link, https://bugzilla.kernel.org/show_bug.cgi?id=79931. This bug report states that in the function, tmio_hc_stop the switch has no needed breaks. Further more this patch fixes this bug by adding the needed breaks.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- drivers/usb/host/ohci-tmio.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c index bb40958..d2b5382 100644 --- a/drivers/usb/host/ohci-tmio.c +++ b/drivers/usb/host/ohci-tmio.c @@ -100,12 +100,16 @@ static void tmio_stop_hc(struct platform_device *dev) switch (ohci->num_ports) { default: dev_err(&dev->dev, "Unsupported amount of ports: %d\n", ohci->num_ports); + break; case 3: pm |= CCR_PM_USBPW3; + break; case 2: pm |= CCR_PM_USBPW2; + break; case 1: pm |= CCR_PM_USBPW1; + break; } tmio_iowrite8(0, tmio->ccr + CCR_INTC); tmio_iowrite8(0, tmio->ccr + CCR_ILME); -- 1.9.1
If someone wants to send out this patch for me,that would be great :). Nick
Please Nick, stop spamming the list with your patches. I _really_ doubt that anyone ever will try to get your patches merged since you've managed to get banned from vger and got a somewhat flawed reputation. On Thu, Aug 14, 2014 at 8:06 PM, Nick Krause <xerofoify@gmail.com> wrote:
On Thu, Aug 14, 2014 at 2:05 PM, Nicholas Krause <xerofoify@gmail.com> wrote:
I am fixing the bug on at the link, https://bugzilla.kernel.org/show_bug.cgi?id=79931. This bug report states that in the function, tmio_hc_stop the switch has no needed breaks. Further more this patch fixes this bug by adding the needed breaks.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- drivers/usb/host/ohci-tmio.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c index bb40958..d2b5382 100644 --- a/drivers/usb/host/ohci-tmio.c +++ b/drivers/usb/host/ohci-tmio.c @@ -100,12 +100,16 @@ static void tmio_stop_hc(struct platform_device *dev) switch (ohci->num_ports) { default: dev_err(&dev->dev, "Unsupported amount of ports: %d\n", ohci->num_ports); + break; case 3: pm |= CCR_PM_USBPW3; + break; case 2: pm |= CCR_PM_USBPW2; + break; case 1: pm |= CCR_PM_USBPW1; + break; } tmio_iowrite8(0, tmio->ccr + CCR_INTC); tmio_iowrite8(0, tmio->ccr + CCR_ILME); -- 1.9.1
If someone wants to send out this patch for me,that would be great :). Nick
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Thu, Aug 14, 2014 at 2:13 PM, Kristofer Hallin <kristofer.hallin@gmail.com> wrote:
Please Nick, stop spamming the list with your patches. I _really_ doubt that anyone ever will try to get your patches merged since you've managed to get banned from vger and got a somewhat flawed reputation.
On Thu, Aug 14, 2014 at 8:06 PM, Nick Krause <xerofoify@gmail.com> wrote:
On Thu, Aug 14, 2014 at 2:05 PM, Nicholas Krause <xerofoify@gmail.com> wrote:
I am fixing the bug on at the link, https://bugzilla.kernel.org/show_bug.cgi?id=79931. This bug report states that in the function, tmio_hc_stop the switch has no needed breaks. Further more this patch fixes this bug by adding the needed breaks.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- drivers/usb/host/ohci-tmio.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c index bb40958..d2b5382 100644 --- a/drivers/usb/host/ohci-tmio.c +++ b/drivers/usb/host/ohci-tmio.c @@ -100,12 +100,16 @@ static void tmio_stop_hc(struct platform_device *dev) switch (ohci->num_ports) { default: dev_err(&dev->dev, "Unsupported amount of ports: %d\n", ohci->num_ports); + break; case 3: pm |= CCR_PM_USBPW3; + break; case 2: pm |= CCR_PM_USBPW2; + break; case 1: pm |= CCR_PM_USBPW1; + break; } tmio_iowrite8(0, tmio->ccr + CCR_INTC); tmio_iowrite8(0, tmio->ccr + CCR_ILME); -- 1.9.1
If someone wants to send out this patch for me,that would be great :). Nick
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Kristofer, I understand that too but this patch works and builds I have tested it completely. Look I got off on the wrong start and I am starting to improve my repo but seems impossible if people are just going to forget about my good patches. Nick
Nick, To clean to clean up your online reputation take a long vacation. *Seriously*. Do not send any more e-mail, patch or apologize. You do not need to be a kernel developer right now. You can restart next year. For now, just read, read this list, read other lists. You are trying to rush to archive something that take years to accomplish. Please take my advice, go away, and come next year. *Seriously*. In the meantime, read books about linux, install Gentoo linux or arch linux, do linux tutorials, build you hello world kernel module, make a appointment with a psychologist. *Seriously. * We need to forget about you for a while. Thanks Tanure
On Thu, 14 Aug 2014 14:18:40 -0400, Nick Krause said:
case 3: pm |= CCR_PM_USBPW3; + break; case 2: pm |= CCR_PM_USBPW2; + break; case 1: pm |= CCR_PM_USBPW1; + break;
I understand that too but this patch works and builds I have tested it completely.
No, you haven't. Far from it. If you were testing it "completely", you would have found an actual Toshiba Mobile or other hardware that uses this driver, and had logs to show how it used to misbehave due to this bug, and that it worked correctly now. And you would have noticed, and explained, why the #defines for CCR_PM_USBPW2 and CCR_PM_USBPW3 are the same value. In fact, that's why the compiler whined, *not* because of the missing break; code. So sticking in breaks and not even mentioning the #defines shows that you did ABSOLUTELY ZERO to actually understand what the compiler was telling you. Note that there's perfectly valid reasons for fall-through in a C switch - see Tom Duff for a classic example (yes, Dennis Ritchie said it was valid C): http://www.lysator.liu.se/c/duffs-device.html The #defines could possibly be intentionally that way if the chip is weird and uses 2 pins to control 3 ports in a non-intuitive way - and if they're active-low bits even the lack of break; after the default: warning case could be proper, disabling all ports if an invalid one is specified. And there's no indication you even *bothered* to check that possibility - which would mean applying your patch would break a properly written driver. And even worse, there's no indication you actually understood what the compile warning was telling you.
Look I got off on the wrong start and I am starting to improve my repo but seems
If you think you're improving your rep with these poor patches, you're delusional.
impossible if people are just going to forget about my good patches.
We'll discuss that when you actually submit one that isn't a steaming pile of dingo's kidneys. Do yourself a favor - try to resist the temptation to post a patch for at least 30 to 60 days, *no matter how correct you think it is*.
On Thu, Aug 14, 2014 at 4:51 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 14 Aug 2014 14:18:40 -0400, Nick Krause said:
case 3: pm |= CCR_PM_USBPW3; + break; case 2: pm |= CCR_PM_USBPW2; + break; case 1: pm |= CCR_PM_USBPW1; + break;
I understand that too but this patch works and builds I have tested it completely.
No, you haven't. Far from it.
If you were testing it "completely", you would have found an actual Toshiba Mobile or other hardware that uses this driver, and had logs to show how it used to misbehave due to this bug, and that it worked correctly now.
And you would have noticed, and explained, why the #defines for CCR_PM_USBPW2 and CCR_PM_USBPW3 are the same value. In fact, that's why the compiler whined, *not* because of the missing break; code. So sticking in breaks and not even mentioning the #defines shows that you did ABSOLUTELY ZERO to actually understand what the compiler was telling you.
Note that there's perfectly valid reasons for fall-through in a C switch - see Tom Duff for a classic example (yes, Dennis Ritchie said it was valid C):
http://www.lysator.liu.se/c/duffs-device.html
The #defines could possibly be intentionally that way if the chip is weird and uses 2 pins to control 3 ports in a non-intuitive way - and if they're active-low bits even the lack of break; after the default: warning case could be proper, disabling all ports if an invalid one is specified.
And there's no indication you even *bothered* to check that possibility - which would mean applying your patch would break a properly written driver.
And even worse, there's no indication you actually understood what the compile warning was telling you.
Look I got off on the wrong start and I am starting to improve my repo but seems
If you think you're improving your rep with these poor patches, you're delusional.
impossible if people are just going to forget about my good patches.
We'll discuss that when you actually submit one that isn't a steaming pile of dingo's kidneys.
Do yourself a favor - try to resist the temptation to post a patch for at least 30 to 60 days, *no matter how correct you think it is*.
Very well then I will not do any more patches for the next month and only read the list. Nick
Look I got off on the wrong start and I am starting to improve my repo but seems
If you think you're improving your rep with these poor patches, you're delusional.
impossible if people are just going to forget about my good patches.
We'll discuss that when you actually submit one that isn't a steaming pile of dingo's kidneys.
Do yourself a favor - try to resist the temptation to post a patch for at least 30 to 60 days, *no matter how correct you think it is*.
Plz start listening to what people are telling you. Don't post patches here. If you want to make them, fine. Keep them in your local machine for now. Heed to the advice of seniors here otherwise people will just start ignoring you _completely_ and you won't get any help after that. Also, I've observed that you're not trying to understand what the code is doing. You're looking at every build error/bug as a C programming problem (which too unfortunately you're not understanding completely) and have no clue of the context in which it's written. Thats why Valdis and many others are finding so many faults in your 'patches'. They are wrong at both levels! Please go through some C tutorials and get a good grasp of the language. Only _then_ attempt to get your hands dirty with kernel code. This is my last advice. After this, I will delete all patch related emails from you without reading it. Good luck, -mandeep
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Thu, Aug 14, 2014 at 5:03 PM, Mandeep Sandhu <mandeepsandhu.chd@gmail.com> wrote:
Look I got off on the wrong start and I am starting to improve my repo but seems
If you think you're improving your rep with these poor patches, you're delusional.
impossible if people are just going to forget about my good patches.
We'll discuss that when you actually submit one that isn't a steaming pile of dingo's kidneys.
Do yourself a favor - try to resist the temptation to post a patch for at least 30 to 60 days, *no matter how correct you think it is*.
Plz start listening to what people are telling you. Don't post patches here. If you want to make them, fine. Keep them in your local machine for now. Heed to the advice of seniors here otherwise people will just start ignoring you _completely_ and you won't get any help after that.
Also, I've observed that you're not trying to understand what the code is doing. You're looking at every build error/bug as a C programming problem (which too unfortunately you're not understanding completely) and have no clue of the context in which it's written. Thats why Valdis and many others are finding so many faults in your 'patches'. They are wrong at both levels!
Please go through some C tutorials and get a good grasp of the language. Only _then_ attempt to get your hands dirty with kernel code.
This is my last advice. After this, I will delete all patch related emails from you without reading it.
Good luck, -mandeep
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Mandeep, I am learned C. Perhaps I am a little rusty and need to review. Nick
On Thu, 14 Aug 2014 17:13:28 -0400, Nick Krause said:
I am learned C. Perhaps I am a little rusty and need to review.
We've seen very little evidence that you *ever* really understood C at all, and you're *far* from "a little rusty". It's been some 23 years since I've hacked any code in IBM's Pascal/VS, and 29 since I had to do maintenance work on PL/I code, and I *still* remember more of those than you remember of C. (I'll admit that my mad Snobol4 skilz have pretty much evaporated, though ;) http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
On Thu, Aug 14, 2014 at 5:38 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 14 Aug 2014 17:13:28 -0400, Nick Krause said:
I am learned C. Perhaps I am a little rusty and need to review.
We've seen very little evidence that you *ever* really understood C at all, and you're *far* from "a little rusty". It's been some 23 years since I've hacked any code in IBM's Pascal/VS, and 29 since I had to do maintenance work on PL/I code, and I *still* remember more of those than you remember of C. (I'll admit that my mad Snobol4 skilz have pretty much evaporated, though ;)
http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect I learned C like two years ago and never really practiced it that much to be honest. In addition I will come back in the future about I have read The C Programming Language. Cheers Nick
On Thu, Aug 14, 2014 at 6:12 PM, Nick Krause <xerofoify@gmail.com> wrote:
On Thu, Aug 14, 2014 at 5:38 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 14 Aug 2014 17:13:28 -0400, Nick Krause said:
I am learned C. Perhaps I am a little rusty and need to review.
We've seen very little evidence that you *ever* really understood C at all, and you're *far* from "a little rusty". It's been some 23 years since I've hacked any code in IBM's Pascal/VS, and 29 since I had to do maintenance work on PL/I code, and I *still* remember more of those than you remember of C. (I'll admit that my mad Snobol4 skilz have pretty much evaporated, though ;)
http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect I learned C like two years ago and never really practiced it that much to be honest. In addition I will come back in the future about I have read The C Programming Language. Cheers Nick Thanks for pointing me in the right direction , I really do need to brush up on my C. Sorry for wasting your time. Nick
On Thu, Aug 14, 2014 at 7:46 PM, Nick Krause <xerofoify@gmail.com> wrote:
On Thu, Aug 14, 2014 at 6:12 PM, Nick Krause <xerofoify@gmail.com> wrote:
On Thu, Aug 14, 2014 at 5:38 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 14 Aug 2014 17:13:28 -0400, Nick Krause said:
I am learned C. Perhaps I am a little rusty and need to review.
We've seen very little evidence that you *ever* really understood C at all, and you're *far* from "a little rusty". It's been some 23 years since I've hacked any code in IBM's Pascal/VS, and 29 since I had to do maintenance work on PL/I code, and I *still* remember more of those than you remember of C. (I'll admit that my mad Snobol4 skilz have pretty much evaporated, though ;)
http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect I learned C like two years ago and never really practiced it that much to be honest. In addition I will come back in the future about I have read The C Programming Language. Cheers Nick Thanks for pointing me in the right direction , I really do need to brush up on my C. Sorry for wasting your time. Nick
Nick, The linux kernel has some of the most complex c code on the planet. It is seriously not a place to "brush-up", "practice", or "learn". A few _years_ of current c experience is pretty much a must to truly grok the kernel. Once you have that as a base, then it takes a lot of real study to comprehend the complex use cases used in the linux kernel. I suggest you find a userspace project and work with it for a year or two before you jump back into the kernel. Personally, I find the libyal family of userspace c libraries interesting. The code base is much smaller, but works with filesystems and is has multi-threaded needs. The main author is crazy smart (works for Google), so I'm not saying he needs your help. I'm saying the code base is small enough you might be able to get your arms around it and really understand it. That can help you understand the data structures used in filesystems, complex volume systems, and encryption. https://code.google.com/p/libyal/wiki/Overview You said you have an interest in filesystems (as do I). Looking at the filesystem section of that overview a couple of his targeted libraries haven't even been started yet. You code will likely be throwaway code for your first effort or two, but File systems Several libraries for different types of filesystems don't even have code yet. libfsclfs; Common Log File System (CLFS) format libfshfs; Hierarchical File System (HFS) format - at the moment documentation only libfsntfs; New Technology File System (NTFS) format - at the moment documentation only libfsrefs; Resilient File System (ReFS) format - at the moment documentation only For me, if I was trying to learn about filesystems, that would be a fun way to hack away at new code. Also, libyal has lots of low level libraries you can build upon so your not starting from scratch. Further there are lots of "tools" written that provide high-level end-user applications. If you'd rather look at volumes (similar to device mapper code), there are these projects: libbde; BitLocker drive encryption (BDE) libfvde; FileVault drive encryption (FVDE) libluksde; LUKS Disk Encryption - at the moment documentation only libvslvm; Linux Logical Volume Manager (LVM) volume system format - at the moment documentation only libvshadow; Volume Shadow Snapshot (VSS) format libvslibs; several libraries for different types of volume systems. - at the moment documentation only Or maybe you'd like to learn about virtual disks such as VMs use: Image formats Several libraries for accessing different types of storage media: libodraw; optical disc (split) RAW image format (bin/cue, iso/cue) libsmdev; storage media devices libsmraw; (split) RAW image format libewf; Expert Witness Compression Format (EWF) image format libqcow; QEMU Copy-On-Write (QCOW) image format libvhdi; Virtual Hard Disk (VHD) image format libvmdk; VMware Virtual Disk (VMDK) format FYI: I maintain many of the above for openSUSE and have the packages in the main distro. My to do list for this weekend is to package up libqcow, libvhdi, and libvmdk. That being my weekend plan is why I have libyal in my head at the moment. Greg
On Thu, Aug 14, 2014 at 10:16 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
On Thu, Aug 14, 2014 at 7:46 PM, Nick Krause <xerofoify@gmail.com> wrote:
On Thu, Aug 14, 2014 at 6:12 PM, Nick Krause <xerofoify@gmail.com> wrote:
On Thu, Aug 14, 2014 at 5:38 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 14 Aug 2014 17:13:28 -0400, Nick Krause said:
I am learned C. Perhaps I am a little rusty and need to review.
We've seen very little evidence that you *ever* really understood C at all, and you're *far* from "a little rusty". It's been some 23 years since I've hacked any code in IBM's Pascal/VS, and 29 since I had to do maintenance work on PL/I code, and I *still* remember more of those than you remember of C. (I'll admit that my mad Snobol4 skilz have pretty much evaporated, though ;)
http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect I learned C like two years ago and never really practiced it that much to be honest. In addition I will come back in the future about I have read The C Programming Language. Cheers Nick Thanks for pointing me in the right direction , I really do need to brush up on my C. Sorry for wasting your time. Nick
Nick,
The linux kernel has some of the most complex c code on the planet. It is seriously not a place to "brush-up", "practice", or "learn".
A few _years_ of current c experience is pretty much a must to truly grok the kernel. Once you have that as a base, then it takes a lot of real study to comprehend the complex use cases used in the linux kernel.
I suggest you find a userspace project and work with it for a year or two before you jump back into the kernel. Personally, I find the libyal family of userspace c libraries interesting. The code base is much smaller, but works with filesystems and is has multi-threaded needs. The main author is crazy smart (works for Google), so I'm not saying he needs your help. I'm saying the code base is small enough you might be able to get your arms around it and really understand it. That can help you understand the data structures used in filesystems, complex volume systems, and encryption.
https://code.google.com/p/libyal/wiki/Overview
You said you have an interest in filesystems (as do I).
Looking at the filesystem section of that overview a couple of his targeted libraries haven't even been started yet. You code will likely be throwaway code for your first effort or two, but File systems
Several libraries for different types of filesystems don't even have code yet.
libfsclfs; Common Log File System (CLFS) format libfshfs; Hierarchical File System (HFS) format - at the moment documentation only libfsntfs; New Technology File System (NTFS) format - at the moment documentation only libfsrefs; Resilient File System (ReFS) format - at the moment documentation only
For me, if I was trying to learn about filesystems, that would be a fun way to hack away at new code. Also, libyal has lots of low level libraries you can build upon so your not starting from scratch. Further there are lots of "tools" written that provide high-level end-user applications.
If you'd rather look at volumes (similar to device mapper code), there are these projects:
libbde; BitLocker drive encryption (BDE) libfvde; FileVault drive encryption (FVDE) libluksde; LUKS Disk Encryption - at the moment documentation only libvslvm; Linux Logical Volume Manager (LVM) volume system format - at the moment documentation only libvshadow; Volume Shadow Snapshot (VSS) format libvslibs; several libraries for different types of volume systems. - at the moment documentation only
Or maybe you'd like to learn about virtual disks such as VMs use:
Image formats
Several libraries for accessing different types of storage media:
libodraw; optical disc (split) RAW image format (bin/cue, iso/cue) libsmdev; storage media devices libsmraw; (split) RAW image format libewf; Expert Witness Compression Format (EWF) image format libqcow; QEMU Copy-On-Write (QCOW) image format libvhdi; Virtual Hard Disk (VHD) image format libvmdk; VMware Virtual Disk (VMDK) format
FYI: I maintain many of the above for openSUSE and have the packages in the main distro. My to do list for this weekend is to package up libqcow, libvhdi, and libvmdk. That being my weekend plan is why I have libyal in my head at the moment.
Greg Greg, Thats very understandable I will look into something else for now. Nick
On Thu, Aug 14, 2014 at 10:29 PM, Nick Krause <xerofoify@gmail.com> wrote:
On Thu, Aug 14, 2014 at 10:16 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
On Thu, Aug 14, 2014 at 7:46 PM, Nick Krause <xerofoify@gmail.com> wrote:
On Thu, Aug 14, 2014 at 6:12 PM, Nick Krause <xerofoify@gmail.com> wrote:
On Thu, Aug 14, 2014 at 5:38 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 14 Aug 2014 17:13:28 -0400, Nick Krause said:
I am learned C. Perhaps I am a little rusty and need to review.
We've seen very little evidence that you *ever* really understood C at all, and you're *far* from "a little rusty". It's been some 23 years since I've hacked any code in IBM's Pascal/VS, and 29 since I had to do maintenance work on PL/I code, and I *still* remember more of those than you remember of C. (I'll admit that my mad Snobol4 skilz have pretty much evaporated, though ;)
http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect I learned C like two years ago and never really practiced it that much to be honest. In addition I will come back in the future about I have read The C Programming Language. Cheers Nick Thanks for pointing me in the right direction , I really do need to brush up on my C. Sorry for wasting your time. Nick
Nick,
The linux kernel has some of the most complex c code on the planet. It is seriously not a place to "brush-up", "practice", or "learn".
A few _years_ of current c experience is pretty much a must to truly grok the kernel. Once you have that as a base, then it takes a lot of real study to comprehend the complex use cases used in the linux kernel.
I suggest you find a userspace project and work with it for a year or two before you jump back into the kernel. Personally, I find the libyal family of userspace c libraries interesting. The code base is much smaller, but works with filesystems and is has multi-threaded needs. The main author is crazy smart (works for Google), so I'm not saying he needs your help. I'm saying the code base is small enough you might be able to get your arms around it and really understand it. That can help you understand the data structures used in filesystems, complex volume systems, and encryption.
https://code.google.com/p/libyal/wiki/Overview
You said you have an interest in filesystems (as do I).
Looking at the filesystem section of that overview a couple of his targeted libraries haven't even been started yet. You code will likely be throwaway code for your first effort or two, but File systems
Several libraries for different types of filesystems don't even have code yet.
libfsclfs; Common Log File System (CLFS) format libfshfs; Hierarchical File System (HFS) format - at the moment documentation only libfsntfs; New Technology File System (NTFS) format - at the moment documentation only libfsrefs; Resilient File System (ReFS) format - at the moment documentation only
For me, if I was trying to learn about filesystems, that would be a fun way to hack away at new code. Also, libyal has lots of low level libraries you can build upon so your not starting from scratch. Further there are lots of "tools" written that provide high-level end-user applications.
If you'd rather look at volumes (similar to device mapper code), there are these projects:
libbde; BitLocker drive encryption (BDE) libfvde; FileVault drive encryption (FVDE) libluksde; LUKS Disk Encryption - at the moment documentation only libvslvm; Linux Logical Volume Manager (LVM) volume system format - at the moment documentation only libvshadow; Volume Shadow Snapshot (VSS) format libvslibs; several libraries for different types of volume systems. - at the moment documentation only
Or maybe you'd like to learn about virtual disks such as VMs use:
Image formats
Several libraries for accessing different types of storage media:
libodraw; optical disc (split) RAW image format (bin/cue, iso/cue) libsmdev; storage media devices libsmraw; (split) RAW image format libewf; Expert Witness Compression Format (EWF) image format libqcow; QEMU Copy-On-Write (QCOW) image format libvhdi; Virtual Hard Disk (VHD) image format libvmdk; VMware Virtual Disk (VMDK) format
FYI: I maintain many of the above for openSUSE and have the packages in the main distro. My to do list for this weekend is to package up libqcow, libvhdi, and libvmdk. That being my weekend plan is why I have libyal in my head at the moment.
Greg Greg, Thats very understandable I will look into something else for now. Nick I am going to work with postrqesql for now and learn from there. Nick
On Thu, Aug 14, 2014 at 10:42 PM, Nick Krause <xerofoify@gmail.com> wrote:
On Thu, Aug 14, 2014 at 10:29 PM, Nick Krause <xerofoify@gmail.com> wrote:
On Thu, Aug 14, 2014 at 10:16 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
On Thu, Aug 14, 2014 at 7:46 PM, Nick Krause <xerofoify@gmail.com> wrote:
On Thu, Aug 14, 2014 at 6:12 PM, Nick Krause <xerofoify@gmail.com> wrote:
On Thu, Aug 14, 2014 at 5:38 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 14 Aug 2014 17:13:28 -0400, Nick Krause said:
I am learned C. Perhaps I am a little rusty and need to review.
We've seen very little evidence that you *ever* really understood C at all, and you're *far* from "a little rusty". It's been some 23 years since I've hacked any code in IBM's Pascal/VS, and 29 since I had to do maintenance work on PL/I code, and I *still* remember more of those than you remember of C. (I'll admit that my mad Snobol4 skilz have pretty much evaporated, though ;)
http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect I learned C like two years ago and never really practiced it that much to be honest. In addition I will come back in the future about I have read The C Programming Language. Cheers Nick Thanks for pointing me in the right direction , I really do need to brush up on my C. Sorry for wasting your time. Nick
Nick,
The linux kernel has some of the most complex c code on the planet. It is seriously not a place to "brush-up", "practice", or "learn".
A few _years_ of current c experience is pretty much a must to truly grok the kernel. Once you have that as a base, then it takes a lot of real study to comprehend the complex use cases used in the linux kernel.
I suggest you find a userspace project and work with it for a year or two before you jump back into the kernel. Personally, I find the libyal family of userspace c libraries interesting. The code base is much smaller, but works with filesystems and is has multi-threaded needs. The main author is crazy smart (works for Google), so I'm not saying he needs your help. I'm saying the code base is small enough you might be able to get your arms around it and really understand it. That can help you understand the data structures used in filesystems, complex volume systems, and encryption.
https://code.google.com/p/libyal/wiki/Overview
You said you have an interest in filesystems (as do I).
Looking at the filesystem section of that overview a couple of his targeted libraries haven't even been started yet. You code will likely be throwaway code for your first effort or two, but File systems
Several libraries for different types of filesystems don't even have code yet.
libfsclfs; Common Log File System (CLFS) format libfshfs; Hierarchical File System (HFS) format - at the moment documentation only libfsntfs; New Technology File System (NTFS) format - at the moment documentation only libfsrefs; Resilient File System (ReFS) format - at the moment documentation only
For me, if I was trying to learn about filesystems, that would be a fun way to hack away at new code. Also, libyal has lots of low level libraries you can build upon so your not starting from scratch. Further there are lots of "tools" written that provide high-level end-user applications.
If you'd rather look at volumes (similar to device mapper code), there are these projects:
libbde; BitLocker drive encryption (BDE) libfvde; FileVault drive encryption (FVDE) libluksde; LUKS Disk Encryption - at the moment documentation only libvslvm; Linux Logical Volume Manager (LVM) volume system format - at the moment documentation only libvshadow; Volume Shadow Snapshot (VSS) format libvslibs; several libraries for different types of volume systems. - at the moment documentation only
Or maybe you'd like to learn about virtual disks such as VMs use:
Image formats
Several libraries for accessing different types of storage media:
libodraw; optical disc (split) RAW image format (bin/cue, iso/cue) libsmdev; storage media devices libsmraw; (split) RAW image format libewf; Expert Witness Compression Format (EWF) image format libqcow; QEMU Copy-On-Write (QCOW) image format libvhdi; Virtual Hard Disk (VHD) image format libvmdk; VMware Virtual Disk (VMDK) format
FYI: I maintain many of the above for openSUSE and have the packages in the main distro. My to do list for this weekend is to package up libqcow, libvhdi, and libvmdk. That being my weekend plan is why I have libyal in my head at the moment.
Greg Greg, Thats very understandable I will look into something else for now. Nick I am going to work with postrqesql for now and learn from there. Nick I forget about the Eudyptula challenge, I am going to start with that and I will make an agreement that you guys. Until I complete all of the challenges correctly , I am not allowed to sent out any more patches. If I do I don't want any response what so ever , no matter how hard I plead. If this is a deal , Greg and others please reply. Thanks for the Help and I still don't known how the hell you haven't given up on me yet, Nick
I forget about the Eudyptula challenge, I am going to start with that and I will make an agreement that you guys. Until I complete all of the challenges correctly , I am not allowed to sent out any more patches. If I do I don't want any response what so ever , no matter how hard I plead. If this is a deal , Greg and others please reply.
Warning! Do not send any emails to the kernelnewbies mailing list about the eudyptula challenge....otherwise you will be removed from the challenge. I am not a person in control of the challenge, but I was just removed today for doing this. So be sure to read through the rules carefully! -Jaret
On Thu, Aug 14, 2014 at 11:42 PM, Jaret Flores <jarflores@gmail.com> wrote:
I forget about the Eudyptula challenge, I am going to start with that and I will make an agreement that you guys. Until I complete all of the challenges correctly , I am not allowed to sent out any more patches. If I do I don't want any response what so ever , no matter how hard I plead. If this is a deal , Greg and others please reply.
Warning! Do not send any emails to the kernelnewbies mailing list about the eudyptula challenge....otherwise you will be removed from the challenge. I am not a person in control of the challenge, but I was just removed today for doing this. So be sure to read through the rules carefully! -Jaret I failed too, asked about the first task(fail) and got removed. Nick
On Thu, Aug 14, 2014 at 11:43 PM, Nick Krause <xerofoify@gmail.com> wrote:
On Thu, Aug 14, 2014 at 11:42 PM, Jaret Flores <jarflores@gmail.com> wrote:
I forget about the Eudyptula challenge, I am going to start with that and I will make an agreement that you guys. Until I complete all of the challenges correctly , I am not allowed to sent out any more patches. If I do I don't want any response what so ever , no matter how hard I plead. If this is a deal , Greg and others please reply.
Warning! Do not send any emails to the kernelnewbies mailing list about the eudyptula challenge....otherwise you will be removed from the challenge. I am not a person in control of the challenge, but I was just removed today for doing this. So be sure to read through the rules carefully! -Jaret I failed too, asked about the first task(fail) and got removed. Nick
In addition thanks to Greg and Vadis for putting up my crap :(. I hope after I get back from the challenge I able to help more. Nick
participants (7)
-
Greg Freemyer -
Jaret Flores -
Kristofer Hallin -
Lucas Tanure -
Mandeep Sandhu -
Nick Krause -
Valdis.Kletnieks＠vt.edu