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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #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)
               		[B]goto out;[/B]
               
              -	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;
              -
               	[B]return 0;[/B]
               
              [B] out:[/B]
              and not something this trivial:

              Code:
              if (core_dev_setup_virtual_lun0() >= 0)
               		[B]return 0;[/B]
               
              -	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

                    Working...
                    X