When is kernel org coming back up

Special note to back-porters: It seems to be a common and useful practice to insert an indication of the origin of a patch at the top of the commit message just after the subject line to facilitate tracking. For instance, here's what we see in a 3. Whatever the format, this information provides a valuable help to people tracking your trees, and to people trying to troubleshoot bugs in your tree.

If a person was not directly involved in the preparation or handling of a patch but wishes to signify and record their approval of it then they can ask to have an Acked-by: line added to the patch's changelog. Acked-by: is often used by the maintainer of the affected code when that maintainer neither contributed to nor forwarded the patch.

Acked-by: is not as formal as Signed-off-by:. It is a record that the acker has at least reviewed the patch and has indicated acceptance. Hence patch mergers will sometimes manually convert an acker's "yep, looks good to me" into an Acked-by: but note that it is usually better to ask for an explicit ack.

Acked-by: does not necessarily indicate acknowledgement of the entire patch. For example, if a patch affects multiple subsystems and has an Acked-by: from one subsystem maintainer then this usually indicates acknowledgement of just the part which affects that maintainer's code.

Judgement should be used here. When in doubt people should refer to the original discussion in the mailing list archives. If a person has had the opportunity to comment on a patch, but has not provided such comments, you may optionally add a Cc: tag to the patch.

This is the only tag which might be added without an explicit action by the person it names - but it should indicate that this person was copied on the patch. This tag documents that potentially interested parties have been included in the discussion. Co-developed-by: states that the patch was co-created by multiple developers; it is a used to give attribution to co-authors in addition to the author attributed by the From: tag when several people work on a single patch.

Since Co-developed-by: denotes authorship, every Co-developed-by: must be immediately followed by a Signed-off-by: of the associated co-author. Standard sign-off procedure applies, i. Notably, the last Signed-off-by: must always be that of the developer submitting the patch.

Note, the From: tag is optional when the From: author is also the person and email listed in the From: line of the email header. The Reported-by tag gives credit to people who find bugs and report them and it hopefully inspires them to help us again in the future.

Please note that if the bug was reported in private, then ask for permission first before using the Reported-by tag. A Tested-by: tag indicates that the patch has been successfully tested in some environment by the person named. This tag informs maintainers that some testing has been performed, provides a means to locate testers for future patches, and ensures credit for the testers.

Reviewed-by:, instead, indicates that the patch has been reviewed and found acceptable according to the Reviewer's Statement:. A Reviewed-by tag is a statement of opinion that the patch is an appropriate modification of the kernel without any remaining serious technical issues. Any interested reviewer who has done the work can offer a Reviewed-by tag for a patch. This tag serves to give credit to reviewers and to inform maintainers of the degree of review which has been done on the patch.

Reviewed-by: tags, when supplied by reviewers known to understand the subject area and to perform thorough reviews, will normally increase the likelihood of your patch getting into the kernel. A Suggested-by: tag indicates that the patch idea is suggested by the person named and ensures credit to the person for the idea.

Please note that this tag should not be added without the reporter's permission, especially if the idea was not posted in a public forum. That said, if we diligently credit our idea reporters, they will, hopefully, be inspired to help us again in the future.

A Fixes: tag indicates that the patch fixes an issue in a previous commit. It is used to make it easy to determine where a bug originated, which can help review a bug fix. This tag also assists the stable kernel team in determining which stable kernel versions should receive your fix. This is the preferred method for indicating a bug fixed by the patch. See 2 Describe your changes for more details. This section describes how the patch itself should be formatted. Note that, if you have your patches stored in a git repository, proper patch formatting can be had with git format-patch.

The tools cannot create the necessary text, though, so read the instructions below anyway. The Subject line format makes it very easy to sort the emails alphabetically by subject line - pretty much any email reader will support that - since because the sequence number is zero-padded, the numerical and alphabetic sort is the same. The subsystem in the email's Subject should identify which area or subsystem of the kernel is being patched. The summary phrase in the email's Subject should concisely describe the patch which that email contains.

The summary phrase should not be a filename. Do not use the same summary phrase for every patch in a whole patch series where a patch series is an ordered sequence of multiple, related patches. Bear in mind that the summary phrase of your email becomes a globally-unique identifier for that patch. It propagates all the way into the git changelog. The summary phrase may later be used in developer discussions which refer to the patch. People will want to google for the summary phrase to read discussion regarding that patch.

It will also be the only thing that people may quickly see when, two or three months later, they are going through perhaps thousands of patches using tools such as gitk or git log --oneline.

For these reasons, the summary must be no more than characters, and it must describe both what the patch changes, as well as why the patch might be necessary. It is challenging to be both succinct and descriptive, but that is what a well-written summary should do. The tags are not considered part of the summary phrase, but describe how the patch should be treated. Common tags might include a version descriptor if the multiple versions of the patch have been sent out in response to comments i.

This assures that developers understand the order in which the patches should be applied and that they have reviewed or applied all of the patches in the patch series.

The from line must be the very first line in the message body, and has the form:. The from line specifies who will be credited as the author of the patch in the permanent changelog.

If the from line is missing, then the From: line from the email header will be used to determine the patch author in the changelog. He said officials remain confident of preliminary findings that the attackers were not able to tamper with the source code that millions of organizations use to compile their Linux systems.

Git is the name of the system that tracks changes made to the source code for the Linux kernel. It uses a series of bit cryptographic hashes to account for the revisions. Copies of the repository and all changes are then cached in thousands of locations around the world. A mismatched hash in one or more location would quickly indicate unofficial changes. Kroah-Hartman also told Ars kernel. Officials have developed new tools and procedures since then, but he declined to say what they are.

While there's no evidence that backdoors or other malicious code were surreptitiously inserted, the breach of one of the world's most important software development organizations should nonetheless remain a concern. That's especially true now that we're living in an era where actors of powerful nation-states have been known to hijack Microsoft's official Windows update mechanism and deliberately weaken cryptographic coding standards.

Transparency is more important than ever. Having unnecessary drivers will make the kernel bigger, and can under some circumstances lead to problems: probing for a nonexistent controller card may confuse your other controllers.

A kernel with math-emulation compiled in will still use the coprocessor if one is present: the math emulation will just never get used in that case. The kernel will be slightly larger, but will work on different machines regardless of whether they have a math coprocessor or not. Make sure you have at least gcc 5.

For more information, refer to Minimal requirements to compile the Kernel. Do a make to create a compressed kernel image. It is also possible to do make install if you have lilo installed to suit the kernel makefiles, but you may want to check your particular lilo setup first.

To do the actual install, you have to be root, but none of the normal build should require that. Normally, the kernel build system runs in a fairly quiet mode but not totally silent. However, sometimes you or other kernel developers need to see compile, link, or other commands exactly as they are executed. Keep a backup kernel handy in case something goes wrong. This is especially true for the development releases, since each new release contains new code which has not been debugged.

Make sure you keep a backup of the modules corresponding to that kernel, as well. Booting a kernel directly from a floppy without the assistance of a bootloader such as LILO, is no longer supported. To use the new kernel, save a copy of the old image and copy the new image over the old one. See the LILO docs for more information.

If you ever need to change the default root device, video mode, etc. I managed to successfully install it. It boots. But it can't communicate with the outside world. No packets pass through. I want to try compiling the latest 2. Where else can I download this old kernel? But beware. As kernel. On the other side I just wonder if you setup dhcp networking on SuSE?

Or manually configured the network? Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it;. Sign up to join this community.