Announcement

Collapse
No announcement yet.

Linux 2.6.38-rc6 Kernel Released; Lots Of Small Fixes

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux 2.6.38-rc6 Kernel Released; Lots Of Small Fixes

    Phoronix: Linux 2.6.38-rc6 Kernel Released; Lots Of Small Fixes

    The Linux 2.6.38-rc6 kernel has been released. The 2.6.38 kernel is getting into shape and will soon be released with the sixth release candidate carrying a variety of small fixes throughout this open-source kernel...

    http://www.phoronix.com/vr.php?view=OTEyMA

  • #2
    Sorry, does anyone know what "/proc" were replaced with? How does ps aux and similar will work?

    Comment


    • #3
      Originally posted by crazycheese View Post
      Sorry, does anyone know what "/proc" were replaced with? How does ps aux and similar will work?
      /proc isn't getting removed

      Comment


      • #4
        Originally posted by crazycheese View Post
        Sorry, does anyone know what "/proc" were replaced with? How does ps aux and similar will work?
        [SCSI] target: Remove procfs based target_core_mib.c code
        Linux 2.6.38-rc6 (lwn.net article)

        Comment


        • #5
          Here's the relevant patch on the mailing list: http://www.spinics.net/lists/linux-scsi/msg50177.html

          Sounds like they're removing code that is related to (or, relies on) legacy procfs code, not the /proc code itself.

          Comment


          • #6
            procfs was supposed to store process information, but over the years lots of other odds and ends got tacked into it that were not related to processes. Most of that has since been moved to sysfs or debugfs, but there is still a lot of old deprecated procfs entries that are slowly being removed.

            Comment


            • #7
              Thanks a lot!

              I wonder why they are using goto directive instead of making things simpler (from that link to patch), ie:

              Code:
              if (core_dev_setup_virtual_lun0() < 0)
               		goto out;
               
              -	scsi_target_proc = proc_mkdir("scsi_target", NULL);
              -	if (!(scsi_target_proc)) {
              -		printk(KERN_ERR "proc_mkdir(scsi_target, 0) failed\n");
              -		goto out;
              -	}
              -	ret = init_scsi_target_mib();
              -	if (ret < 0)
              -		goto out;
              -
               	return 0;
               
               out:
              and not something this trivial:

              Code:
              if (core_dev_setup_virtual_lun0() >= 0)
               		return 0;
               
              -	scsi_target_proc = proc_mkdir("scsi_target", NULL);
              -	if (!(scsi_target_proc)) {
              -		printk(KERN_ERR "proc_mkdir(scsi_target, 0) failed\n");
              -		goto out;
              -	}
              -	ret = init_scsi_target_mib();
              -	if (ret < 0)
              -		goto out;
              -
              Is this patch not widely accepted yet..?

              Comment


              • #8
                There's more code behind the out:, just returning has a different effect. Goto is used quite often in the linux kernel, usually in this structure:

                Code:
                void function()
                {
                  initialize_some_stuff();
                  if (failure) goto out;
                  initialize_more_stuff();
                  if (failure) goto out;
                  return success;
                
                out:
                  cleanup_any_half_initialized_resources();
                  return failure;
                }
                it's a poor man's try {} catch {}

                Comment


                • #9
                  Originally posted by rohcQaH View Post
                  There's more
                  Hehe, I understand your point. But why not consider this(not trying to teach anyone..):
                  Code:
                  int function(){
                     do_somestuff();
                     if (failure) { cleanup(); return failure; }
                     do_morestuff();
                     if (failure) { cleanup(); return failure; }
                  return success;
                  }
                  ...
                  void cleanup(){... };
                  I guess the real reason is own preference

                  I was just taught missuse of goto leads to undebuggable code and highers cache usage.

                  Comment


                  • #10
                    Originally posted by crazycheese View Post
                    I was just taught missuse of goto leads to undebuggable code and highers cache usage.
                    Well, I find both solutions quite readable but I'd likely not use goto myself due to habit. I don't understand why 'goto' would lead to 'higher' cache usage than calling an outside function?

                    Comment


                    • #11
                      Originally posted by XorEaxEax View Post
                      Well, I find both solutions quite readable but I'd likely not use goto myself due to habit. I don't understand why 'goto' would lead to 'higher' cache usage than calling an outside function?
                      Well, the code size is meant. Keeping it as lots of smaller islands is better as one large cake. But well, it does not matter anymore. Like whats said in that thread, it is programmer who missuses goto and any keyword/function can be misused. Readability sure means more for the future than a compact less understandable code.

                      Comment


                      • #12
                        A goto label for error handling is more efficient. If you call a function for clean-up, that function needs to know about the state of the function that called it. That means passing arguments. This results in more complex code.

                        Another example where goto is useful is jumping from the middle of one loop into another. This occurs when you are processing a stream of data for example, and need to switch to a different algorithm when certain data appears in the stream. An example is UTF-8 parsing, where you can goto from the current loop inside another loop that handles plain ASCII bytes once you detect a few ASCII bytes in succession.

                        Comment


                        • #13
                          Originally posted by crazycheese View Post
                          Hehe, I understand your point. But why not consider this(not trying to teach anyone..):
                          Code:
                          int function(){
                             do_somestuff();
                             if (failure) { cleanup(); return failure; }
                             do_morestuff();
                             if (failure) { cleanup(); return failure; }
                          return success;
                          }
                          ...
                          void cleanup(){... };
                          probably because a lot of the resources needing cleanup are bound to local variables, which wouldn't be available in a separate cleanup() function. Making them global is a no-go (bigger evil than goto, memory usage, thread safety), passing them explicitely would increase code size over a goto.
                          Also, function calls are slow, forcing the compiler to shuffle all those local variables on the stack until they're in the right order. This can be avoided if the compiler chooses to inline the cleanup() function, but you know what'll happen to code size then.

                          The only valid alternative is the big nested function:
                          Code:
                          void function()
                          {
                            do_somestuff();
                            if (success)
                            {
                              do_morestuff();
                              if (success)
                              {
                                //...
                                return success;
                              }
                            }
                            cleanup_stuff();
                          }
                          That avoids the goto, but gets ugly fast because of other reasons.
                          Both styles suck, but there really is no better way until you introduce exceptions and all the problems related to them. I don't think the linux kernel community is ready to take that step, yet

                          Comment


                          • #14
                            Originally posted by rohcQaH View Post
                            Thanks for explanation

                            Comment


                            • #15
                              Originally posted by rohcQaH View Post
                              probably because a lot of the resources needing cleanup are bound to local variables, which wouldn't be available in a separate cleanup() function.
                              Using macros you can have clean looking code without goto's and without the overhead of functions.

                              Code:
                              int myfunc(...args...)
                              {
                                ...local vars myvar1, myvar2...
                              
                              #define getout() \
                                do \
                                { \
                                  free(myvar1); \
                                  free(myvar2); \
                                  return failure; \
                                } while(0)
                              
                                ...allocate myvar1, myvar2...
                                do_something();
                                if (failure) { getout(); }
                                do_morestuff();
                                if (failure) { getout() }
                                return success;
                              }
                              Of course, what getout() does is specific to the state of the function e.g. myvar1 may not even allocated.

                              If you are OCD'ed to 'goto', you can call the macro goto_out...;-)

                              Comment

                              Working...
                              X