11 added 399 characters in body
source | link

Linus Torvalds has a very strong opinion against kernel changes resulting in userspace regressions (see the question "The Linux kernel: breaking user space" for details).

Interface between userspace and kernel is provided by system calls. Newer kernels can have more system calls, and changes in exiting ones when those changes do not break existing applications. When a system call interface has a flag parameter, new kernels often expose the new functionality with a new bit flag. This way kernel maintains backwards compatibility to old applications.

When it has not been possible to alter existing interface without breaking userspace, additional system calls have been added that provide the extended functionality. This is why there are three versions of dup and two versions of umount system call.

The policy of having a stable userspace is the reason why kernel updates rarely cause issues in userspace applications and you do not generally expect issues after upgrading the kernel.

However same API stability is not guaranteed for kernel interfaces and other implementation details. Sysfs (on /sys) and procsfs (on /proc/) expose kernel implementation details on runtime configuration, hardware, network, processes etc. which are used by low-level applications. It is possible for those interfaces to change in an incompatible way between kernel versions if there is a good reason to. Changes still try to minimize incompatibilities if possible and there are rules for how applications can use the interfaces in a way least likely to cause issues. The impact is also limited because non low-level applications shouldn't be using these interfaces.

@PeterCordes also pointed out if a change in procfs or sysfs breaks an application used by your distributions init scripts, you could have a a problem.

This depends somewhat on how your distribution updates kernel (long term support or mainline) and even then the issues are relatively rare as distributions usually ship the updated tools at the same time.

@StephenKitt added that upgraded userspace might require a newer version of the kernel, in which case the system might not be able to boot with the old kernel and that distribution release notes mention this when appropriate.

Linus Torvalds has a very strong opinion against kernel changes resulting in userspace regressions (see the question "The Linux kernel: breaking user space" for details).

Interface between userspace and kernel is provided by system calls. Newer kernels can have more system calls, and changes in exiting ones when those changes do not break existing applications. When a system call interface has a flag parameter, new kernels often expose the new functionality with a new bit flag. This way kernel maintains backwards compatibility to old applications.

When it has not been possible to alter existing interface without breaking userspace, additional system calls have been added that provide the extended functionality. This is why there are three versions of dup and two versions of umount system call.

The policy of having a stable userspace is the reason why kernel updates rarely cause issues in userspace applications and you do not generally expect issues after upgrading the kernel.

However same API stability is not guaranteed for kernel interfaces and other implementation details. Sysfs (on /sys) and procsfs (on /proc/) expose kernel implementation details on runtime configuration, hardware, network, processes etc. which are used by low-level applications. It is possible for those interfaces to change in an incompatible way between kernel versions if there is a good reason to. Changes still try to minimize incompatibilities if possible and there are rules for how applications can use the interfaces in a way least likely to cause issues. The impact is also limited because non low-level applications shouldn't be using these interfaces.

@PeterCordes also pointed out if a change in procfs or sysfs breaks an application used by your distributions init scripts, you could have a a problem.

This depends somewhat on how your distribution updates kernel (long term support or mainline) and even then the issues are relatively rare as distributions usually ship the updated tools at the same time.

Linus Torvalds has a very strong opinion against kernel changes resulting in userspace regressions (see the question "The Linux kernel: breaking user space" for details).

Interface between userspace and kernel is provided by system calls. Newer kernels can have more system calls, and changes in exiting ones when those changes do not break existing applications. When a system call interface has a flag parameter, new kernels often expose the new functionality with a new bit flag. This way kernel maintains backwards compatibility to old applications.

When it has not been possible to alter existing interface without breaking userspace, additional system calls have been added that provide the extended functionality. This is why there are three versions of dup and two versions of umount system call.

The policy of having a stable userspace is the reason why kernel updates rarely cause issues in userspace applications and you do not generally expect issues after upgrading the kernel.

However same API stability is not guaranteed for kernel interfaces and other implementation details. Sysfs (on /sys) and procsfs (on /proc/) expose kernel implementation details on runtime configuration, hardware, network, processes etc. which are used by low-level applications. It is possible for those interfaces to change in an incompatible way between kernel versions if there is a good reason to. Changes still try to minimize incompatibilities if possible and there are rules for how applications can use the interfaces in a way least likely to cause issues. The impact is also limited because non low-level applications shouldn't be using these interfaces.

@PeterCordes pointed out if a change in procfs or sysfs breaks an application used by your distributions init scripts, you could have a a problem.

This depends somewhat on how your distribution updates kernel (long term support or mainline) and even then the issues are relatively rare as distributions usually ship the updated tools at the same time.

@StephenKitt added that upgraded userspace might require a newer version of the kernel, in which case the system might not be able to boot with the old kernel and that distribution release notes mention this when appropriate.

10 deleted 10 characters in body
source | link

Linus Torvalds has a very strong opinion against kernel changes resulting in userspace regressions (see the question "The Linux kernel: breaking user space" for details).

Interface between userspace and kernel is provided by system calls. Newer kernels can have more system calls, and changes in exiting ones when those changes do not break existing applications. When a system call interface has a flag parameter, new kernels often expose the new functionality with a new bit flag. This way kernel maintains backwards compatibility to old applications.

When it has not been possible to alter existing interface without breaking userspace, additional system calls have been added that provide the extended functionality. This is why there are three versions of dup and two versions of umount system call.

The policy of having a stable userspace is the reason why kernel updates rarely cause issues in userspace applications and you do not generally expect issues after upgrading the kernel.

However same API stability is not guaranteed for kernel interfaces and other implementation details. Sysfs (on /sys) and procsfs (on /proc/) expose kernel implementation details on runtime configuration, hardware, network, processes etc. which are used by low-level applications. It is possible for those interfaces to change in an incompatible way between kernel versions if there is a good reason to. Changes still try to minimize incompatibilities if possible and there are rules for how applications can use the interfaces in a way least likely to cause issues. The impact is also limited because non low-level applications shouldn't be using these interfaces.

EDIT: @PeterCordes also pointed out if a change in procfs or sysfs breaks an application used by your distributions init scripts, you could have a a problem.

This depends somewhat on how your distribution updates kernel (long term support or mainline) and even then the issues are relatively rare as distributions usually ship the updated tools at the same time.

Linus Torvalds has a very strong opinion against kernel changes resulting in userspace regressions (see the question "The Linux kernel: breaking user space" for details).

Interface between userspace and kernel is provided by system calls. Newer kernels can have more system calls, and changes in exiting ones when those changes do not break existing applications. When a system call interface has a flag parameter, new kernels often expose the new functionality with a new bit flag. This way kernel maintains backwards compatibility to old applications.

When it has not been possible to alter existing interface without breaking userspace, additional system calls have been added that provide the extended functionality. This is why there are three versions of dup and two versions of umount system call.

The policy of having a stable userspace is the reason why kernel updates rarely cause issues in userspace applications and you do not generally expect issues after upgrading the kernel.

However same API stability is not guaranteed for kernel interfaces and other implementation details. Sysfs (on /sys) and procsfs (on /proc/) expose kernel implementation details on runtime configuration, hardware, network, processes etc. which are used by low-level applications. It is possible for those interfaces to change in an incompatible way between kernel versions if there is a good reason to. Changes still try to minimize incompatibilities if possible and there are rules for how applications can use the interfaces in a way least likely to cause issues. The impact is also limited because non low-level applications shouldn't be using these interfaces.

EDIT: @PeterCordes also pointed out if a change in procfs or sysfs breaks an application used by your distributions init scripts, you could have a a problem.

This depends somewhat on how your distribution updates kernel (long term support or mainline) and even then the issues are relatively rare as distributions usually ship the updated tools at the same time.

Linus Torvalds has a very strong opinion against kernel changes resulting in userspace regressions (see the question "The Linux kernel: breaking user space" for details).

Interface between userspace and kernel is provided by system calls. Newer kernels can have more system calls, and changes in exiting ones when those changes do not break existing applications. When a system call interface has a flag parameter, new kernels often expose the new functionality with a new bit flag. This way kernel maintains backwards compatibility to old applications.

When it has not been possible to alter existing interface without breaking userspace, additional system calls have been added that provide the extended functionality. This is why there are three versions of dup and two versions of umount system call.

The policy of having a stable userspace is the reason why kernel updates rarely cause issues in userspace applications and you do not generally expect issues after upgrading the kernel.

However same API stability is not guaranteed for kernel interfaces and other implementation details. Sysfs (on /sys) and procsfs (on /proc/) expose kernel implementation details on runtime configuration, hardware, network, processes etc. which are used by low-level applications. It is possible for those interfaces to change in an incompatible way between kernel versions if there is a good reason to. Changes still try to minimize incompatibilities if possible and there are rules for how applications can use the interfaces in a way least likely to cause issues. The impact is also limited because non low-level applications shouldn't be using these interfaces.

@PeterCordes also pointed out if a change in procfs or sysfs breaks an application used by your distributions init scripts, you could have a a problem.

This depends somewhat on how your distribution updates kernel (long term support or mainline) and even then the issues are relatively rare as distributions usually ship the updated tools at the same time.

9 added 3 characters in body
source | link

Linus Torvalds has a very strong opinion against kernel changes resulting in userspace regressions (see the question "The Linux kernel: breaking user space" for details).

Interface between userspace and kernel is provided by system calls. Newer kernels can have more system calls, and changes in exiting ones when those changes do not break existing applications. When a system call interface has a flag parameter, new kernels often expose the new functionality with a new bit flag. This way kernel maintains backwards compatibility to old applications.

When it has not been possible to alter existing interface without breaking userspace, additional system calls have been added that provide the extended functionality. This is why there are three versions of dup and two versions of umount system call.

The policy of having a stable userspace is the reason why kernel updates rarely cause issues in userspace applications and you do not generally expect issues after upgrading the kernel.

However same API stability is not guaranteed for kernel interfaces and other implementation details. Sysfs (on /sys) and procsfs (on /proc/) expose kernel implementation details on runtime configuration, hardware, network, processes etc. which are used by low-level applications. It is possible for those interfaces to change in an incompatible way between kernel versions if there is a good reason to. Changes still try to minimize possible incompatibilities if possible and there are rules for how applications can use the interfaces in a way least likely to cause issues. The impact is also limited because non low-level applications shouldn't be using these interfaces.

EDIT: @PeterCordes also pointed out if a change in procfs or sysfs breaks an application used by your distributions init scripts, you could have a a problem.

This depends somewhat on how your distribution updates kernel (long term support or mainline) and even then the issues are relatively rare as distributions usually shiptship the updated tools at the same time.

Linus Torvalds has a very strong opinion against kernel changes resulting in userspace regressions (see the question "The Linux kernel: breaking user space" for details).

Interface between userspace and kernel is provided by system calls. Newer kernels can have more system calls, and changes in exiting ones when those changes do not break existing applications. When a system call interface has a flag parameter, new kernels often expose the new functionality with a new bit flag. This way kernel maintains backwards compatibility to old applications.

When it has not been possible to alter existing interface without breaking userspace, additional system calls have been added that provide the extended functionality. This is why there are three versions of dup and two versions of umount system call.

The policy of having a stable userspace is the reason why kernel updates rarely cause issues in userspace applications and you do not generally expect issues after upgrading the kernel.

However same API stability is not guaranteed for kernel interfaces and other implementation details. Sysfs (on /sys) and procsfs (on /proc/) expose kernel implementation details on runtime configuration, hardware, network, processes etc. which are used by low-level applications. It is possible for those interfaces to change in an incompatible way between kernel versions if there is a good reason to. Changes still try to minimize possible incompatibilities and there are rules for how applications can use the interfaces in a way least likely to cause issues. The impact is also limited because non low-level applications shouldn't be using these interfaces.

EDIT: @PeterCordes also pointed out if a change in procfs or sysfs breaks an application used by your distributions init scripts, you could have a a problem.

This depends somewhat on how your distribution updates kernel (long term support or mainline) and even then the issues are rare as distributions usually shipt the updated tools at the same time.

Linus Torvalds has a very strong opinion against kernel changes resulting in userspace regressions (see the question "The Linux kernel: breaking user space" for details).

Interface between userspace and kernel is provided by system calls. Newer kernels can have more system calls, and changes in exiting ones when those changes do not break existing applications. When a system call interface has a flag parameter, new kernels often expose the new functionality with a new bit flag. This way kernel maintains backwards compatibility to old applications.

When it has not been possible to alter existing interface without breaking userspace, additional system calls have been added that provide the extended functionality. This is why there are three versions of dup and two versions of umount system call.

The policy of having a stable userspace is the reason why kernel updates rarely cause issues in userspace applications and you do not generally expect issues after upgrading the kernel.

However same API stability is not guaranteed for kernel interfaces and other implementation details. Sysfs (on /sys) and procsfs (on /proc/) expose kernel implementation details on runtime configuration, hardware, network, processes etc. which are used by low-level applications. It is possible for those interfaces to change in an incompatible way between kernel versions if there is a good reason to. Changes still try to minimize incompatibilities if possible and there are rules for how applications can use the interfaces in a way least likely to cause issues. The impact is also limited because non low-level applications shouldn't be using these interfaces.

EDIT: @PeterCordes also pointed out if a change in procfs or sysfs breaks an application used by your distributions init scripts, you could have a a problem.

This depends somewhat on how your distribution updates kernel (long term support or mainline) and even then the issues are relatively rare as distributions usually ship the updated tools at the same time.

8 added 312 characters in body
source | link
7 added 312 characters in body
source | link
6 added 605 characters in body
source | link
5 added 3 characters in body
source | link
4 added 812 characters in body
source | link
3 spelling; paragraphization; remove excess word to satisfy SE minimum edit requirement
source | link
2 grammar
source | link
1
source | link