linux
linux copied to clipboard
torvalds
this code very fast
Hi @ahmetilgin!
Thanks for your contribution to the Linux kernel!
Linux kernel development happens on mailing lists, rather than on GitHub - this GitHub repository is a read-only mirror that isn't used for accepting contributions. So that your change can become part of Linux, please email it to us as a patch.
Sending patches isn't quite as simple as sending a pull request, but fortunately it is a well documented process.
Here's what to do:
- Format your contribution according to kernel requirements
- Decide who to send your contribution to
- Set up your system to send your contribution as an email
- Send your contribution and wait for feedback
How do I format my contribution?
The Linux kernel community is notoriously picky about how contributions are formatted and sent. Fortunately, they have documented their expectations.
Firstly, all contributions need to be formatted as patches. A patch is a plain text document showing the change you want to make to the code, and documenting why it is a good idea.
You can create patches with git format-patch.
Secondly, patches need 'commit messages', which is the human-friendly documentation explaining what the change is and why it's necessary.
Thirdly, changes have some technical requirements. There is a Linux kernel coding style, and there are licensing requirements you need to comply with.
Both of these are documented in the Submitting Patches documentation that is part of the kernel.
Note that you will almost certainly have to modify your existing git commits to satisfy these requirements. Don't worry: there are many guides on the internet for doing this.
Who do I send my contribution to?
The Linux kernel is composed of a number of subsystems. These subsystems are maintained by different people, and have different mailing lists where they discuss proposed changes.
If you don't already know what subsystem your change belongs to, the get_maintainer.pl script in the kernel source can help you.
get_maintainer.pl will take the patch or patches you created in the previous step, and tell you who is responsible for them, and what mailing lists are used. You can also take a look at the MAINTAINERS file by hand.
Make sure that your list of recipients includes a mailing list. If you can't find a more specific mailing list, then LKML - the Linux Kernel Mailing List - is the place to send your patches.
It's not usually necessary to subscribe to the mailing list before you send the patches, but if you're interested in kernel development, subscribing to a subsystem mailing list is a good idea. (At this point, you probably don't need to subscribe to LKML - it is a very high traffic list with about a thousand messages per day, which is often not useful for beginners.)
How do I send my contribution?
Use git send-email, which will ensure that your patches are formatted in the standard manner. In order to use git send-email, you'll need to configure git to use your SMTP email server.
For more information about using git send-email, look at the Git documentation or type git help send-email. There are a number of useful guides and tutorials about git send-email that can be found on the internet.
How do I get help if I'm stuck?
Firstly, don't get discouraged! There are an enormous number of resources on the internet, and many kernel developers who would like to see you succeed.
Many issues - especially about how to use certain tools - can be resolved by using your favourite internet search engine.
If you can't find an answer, there are a few places you can turn:
- Kernel Newbies - this website contains a lot of useful resources for new kernel developers.
- If you'd like a step-by-step, challenge-based introduction to kernel development, the Eudyptula Challenge would be an excellent start.
-
The kernel documentation - see also the
Documentationdirectory in the kernel tree.
If you get really, really stuck, you could try the owners of this bot, @daxtens and @ajdlinux. Please be aware that we do have full-time jobs, so we are almost certainly the slowest way to get answers!
I sent my patch - now what?
You wait.
You can check that your email has been received by checking the mailing list archives for the mailing list you sent your patch to. Messages may not be received instantly, so be patient. Kernel developers are generally very busy people, so it may take a few weeks before your patch is looked at.
Then, you keep waiting. Three things may happen:
- You might get a response to your email. Often these will be comments, which may require you to make changes to your patch, or explain why your way is the best way. You should respond to these comments, and you may need to submit another revision of your patch to address the issues raised.
- Your patch might be merged into the subsystem tree. Code that becomes part of Linux isn't merged into the main repository straight away - it first goes into the subsystem tree, which is managed by the subsystem maintainer. It is then batched up with a number of other changes sent to Linus for inclusion. (This process is described in some detail in the kernel development process guide).
- Your patch might be ignored completely. This happens sometimes - don't take it personally. Here's what to do:
- Wait a bit more - patches often take several weeks to get a response; more if they were sent at a busy time.
- Kernel developers often silently ignore patches that break the rules. Check for obvious violations of the the Submitting Patches guidelines, the style guidelines, and any other documentation you can find about your subsystem. Check that you're sending your patch to the right place.
- Try again later. When you resend it, don't add angry commentary, as that will get your patch ignored. It might also get you silently blacklisted.
Further information
- Working with the kernel development community - the official documentation for new kernel contributors
Happy hacking!
This message was posted by a bot - if you have any questions or suggestions, please talk to my owners, @ajdlinux and @daxtens, or raise an issue at https://github.com/ajdlinux/KernelPRBot.
@ItzLevvie Don't you think it's easier to read? It's now only one line of code!
@ahmetilgin The kernel is written in C. C isn't an interpreted language like JS. Instead, it is compiled. Empty characters and spaces don't affect execution speed.
That being said: It looks much more readable than the current code.
@Blaze349 The Linux kernel takes soooooo long to compile. This will increase compilation speed by removing all the unnecessary whitespace the compiler has to skip over.
@kylelamse Are you joking? Minifying a code doesn't make it 'readable'... In Javascript it's used to reduce bandwidth between server & the user, reduce page execution time & reduce file size
@ahmetilgin don't bother wasting your time on the PR. This won't improve anything except for decreasing file size. Also, there are a lot of comments in the 'minified code' that you've not bothered to remove. But again don't bother about it.
@Jonathan50 If a Linux kernel takes 'soo long to compile' then you need to invest in a better CPU like Xeon. Compiling Android or a kernel requires you to have more cores to speed up the compiling process. If you have less cores then it will take more time to compile.
No one loves the code unless it's a sarcasm
@ItzLevvie I do have to agree, this won't get accepted anyways because of contributing guidelines. So you don't have to worry about it.
@dadur604 no he doesn't need any help.. he's just trying to make the community laugh by committing garbage code.
@Blaze349 C is already fast enough... there's no need to do all the stuff the compiler will do it for you automatically or you can add some flags to optimise it.
@thibmo I believe he's trying to make the community laugh. If it's serious then I would obliviously laugh even more.
@7bf70ec5 Linus Torvalds uses a Macbook Air so...yeah. Also, the kernel isn't written in C# 🤣 . It's written in C and a little Assembly.
@DizAzTor Should be easier. You no longer have to scroll through thousands of lines of code. Having it on one line just makes sense.
I've never laughed at code so hard in my life. Thanks for that! Definitely a much needed contribution. Linus has nothing on this guy.
Perhaps this should go into a new Linux for Comedy branch.
Thats just, thats's hmm what is it?..... It's ART :D Put it in a Museum.
There are still too many lines of code. We should remove the comment at the top of the file. It will help the code compile even faster and we'll have less lines to scroll through.
This should be a GCC pull request. GCC must support partial prefix match of keywords for fast processing of C code. For eg: GCC should match the tokens #inc as #include et al. This will further reduce the compilation time and C file size
You can make it even faster by commenting out the last line.
It slightly alters the behavior, but it'll run almost instantly.
@ahmetilgin You can make your country develop faster by removing yourself.
Blown away, BLAZING FAST!
On Sat, Aug 5, 2017 at 7:59 PM, Michael Diarmid [email protected] wrote:
10/10 would compile.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/torvalds/linux/pull/437#issuecomment-320446685, or mute the thread https://github.com/notifications/unsubscribe-auth/ANkje0ACmOQfz5R6d5bFgspdSoZXt763ks5sVHxWgaJpZM4OaL_8 .
Aside from the sarcasm and everything - has anyone actually compiled and tested this?
@tilda My guess: fail I mean, I hope you can see that this would never work..
staticintkernel_init(void*);
@thibmo I'm amazed that you seriously think that we think it would work.
@dschwartz783 As I am amazed that you think that I think that you think it would work. 😛
This code was so good it made me laugh and then cry of joy
On Aug 11, 2017 3:08 AM, "Nicholas Yau" [email protected] wrote:
the best code I've ever seen in my life
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/torvalds/linux/pull/437#issuecomment-321744584, or mute the thread https://github.com/notifications/unsubscribe-auth/AETfrlKR1-hYDq0fX_1SNS7RN4rcSLgjks5sW_3TgaJpZM4OaL_8 .
maybe one day I will be as brilliant as @ahmetilgin, ive tried to contribute #447 in the same light
@Blaze349 There is no such thing as compiled and interpreted languages. Any language can be both compiled and interpreted. Moreover there is nothing in the C standard that talks against being able to use an interpreter instead.
But for science, just how much faster compilation would be if the whole kernel would be seriously minified ? Would minifying + compiling take less time than just compiling ?
My mind refuses to believe that this actually happened. Fucking hilarious.
@ahmetilgin
With Javascript the code is sent to the browser, which then compiles it and executes it on the client machine. Minifying Javascript makes it smaller, meaning that it downloads faster. In addition, part of compiling is parsing - this is where the compiler "understands" the code and having fewer characters (such as whitespace) will make a small improvement in parsing time.
Once code has been compiled, the original size of the source code is irrelevant (except with certain circumstances with Javascript).
C++ (the language that the Linux kernel is written in) doesn't work like Javascript at all. You take the code and compile it on your machine and then copy the compiled result to other machines in order to execute it.
Whitespace in C++ has no effect on performance, because that whitespace is never copied to the machines that are running the C++ program.
The most important thing about making performance enhancements is taking measurements to see if your enhancement has worked. This is called benchmarking. If you had benchmarked your changes, you would have seen that this had no effect on performance.
Don't be discouraged and keep learning.
hi there, I really don't get it? could someone explain? does this infact speed up things? or a gimmic? thanks for your time! :) Majid
On 01/09/2017, Mark [email protected] wrote:
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/torvalds/linux/pull/437#issuecomment-326705606
-- kind regards, Majid Hussain
I think this pull request isn't finished yet. There are still so many files to minify. Please continue your hard work to make this world better and Linux code faster. Cheers!
It is faster when doing code reviews in the future as well, as users who view the file in the browser have a faster loading time due to the reduction of whitespace. Users who check out this file will find faster download and file opening times as well in addition to the faster compiling time!
sorryyoudon'tunderstand.Hi@ahmetilgin!ThanksforyourcontributiontotheLinuxkernel!Linuxkerneldevelopmenthappensonmailinglists,ratherthanonGitHub-thisGitHubrepositoryisaread-onlymirrorthatisn'tusedforacceptingcontributions.SothatyourchangecanbecomepartofLinux,pleaseemailittousasapatch.Sendingpatchesisn'tquiteassimpleassendingapullrequest,butfortunatelyitisawelldocumentedprocess.Here'swhattodo:FormatyourcontributionaccordingtokernelrequirementsDecidewhotosendyourcontributiontoSetupyoursystemtosendyourcontributionasanemailSendyourcontributionandwaitforfeedbackHowdoIformatmycontribution?TheLinuxkernelcommunityisnotoriouslypickyabouthowcontributionsareformattedandsent.Fortunately,theyhavedocumentedtheirexpectations.Firstly,allcontributionsneedtobeformattedaspatches.Apatchisaplaintextdocumentshowingthechangeyouwanttomaketothecode,anddocumentingwhyitisagoodidea.Youcancreatepatcheswithgitformat-patch.Secondly,patchesneed'commitmessages',whichisthehuman-friendlydocumentationexplainingwhatthechangeisandwhyit'snecessary.Thirdly,changeshavesometechnicalrequirements.ThereisaLinuxkernelcodingstyle,andtherearelicensingrequirementsyouneedtocomplywith.BothofthesearedocumentedintheSubmittingPatchesdocumentationthatispartofthekernel.Notethatyouwillalmostcertainlyhavetomodifyyourexistinggitcommitstosatisfytheserequirements.Don'tworry:therearemanyguidesontheinternetfordoingthis.WhodoIsendmycontributionto?TheLinuxkerneliscomposedofanumberofsubsystems.Thesesubsystemsaremaintainedbydifferentpeople,andhavedifferentmailinglistswheretheydiscussproposedchanges.Ifyoudon'talreadyknowwhatsubsystemyourchangebelongsto,theget_maintainer.plscriptinthekernelsourcecanhelpyou.get_maintainer.plwilltakethepatchorpatchesyoucreatedinthepreviousstep,andtellyouwhoisresponsibleforthem,andwhatmailinglistsareused.YoucanalsotakealookattheMAINTAINERSfilebyhand.Makesurethatyourlistofrecipientsincludesamailinglist.Ifyoucan'tfindamorespecificmailinglist,thenLKML-theLinuxKernelMailingList-istheplacetosendyourpatches.It'snotusuallynecessarytosubscribetothemailinglistbeforeyousendthepatches,butifyou'reinterestedinkerneldevelopment,subscribingtoasubsystemmailinglistisagoodidea.(Atthispoint,youprobablydon'tneedtosubscribetoLKML-itisaveryhightrafficlistwithaboutathousandmessagesperday,whichisoftennotusefulforbeginners.)HowdoIsendmycontribution?Usegitsend-email,whichwillensurethatyourpatchesareformattedinthestandardmanner.Inordertousegitsend-email,you'llneedtoconfiguregittouseyourSMTPemailserver.Formoreinformationaboutusinggitsend-email,lookattheGitdocumentationortypegithelpsend-email.Thereareanumberofusefulguidesandtutorialsaboutgitsend-emailthatcanbefoundontheinternet.HowdoIgethelpifI'mstuck?Firstly,don'tgetdiscouraged!Thereareanenormousnumberofresourcesontheinternet,andmanykerneldeveloperswhowouldliketoseeyousucceed.Manyissues-especiallyabouthowtousecertaintools-canberesolvedbyusingyourfavouriteinternetsearchengine.Ifyoucan'tfindananswer,thereareafewplacesyoucanturn:KernelNewbies-thiswebsitecontainsalotofusefulresourcesfornewkerneldevelopers.Ifyou'dlikeastep-by-step,challenge-basedintroductiontokerneldevelopment,theEudyptulaChallengewouldbeanexcellentstart.Thekerneldocumentation-seealsotheDocumentationdirectoryinthekerneltree.Ifyougetreally,reallystuck,youcouldtrytheownersofthisbot,@[email protected],sowearealmostcertainlytheslowestwaytogetanswers!Isentmypatch-nowwhat?Youwait.Youcancheckthatyouremailhasbeenreceivedbycheckingthemailinglistarchivesforthemailinglistyousentyourpatchto.Messagesmaynotbereceivedinstantly,sobepatient.Kerneldevelopersaregenerallyverybusypeople,soitmaytakeafewweeksbeforeyourpatchislookedat.Then,youkeepwaiting.Threethingsmayhappen:Youmightgetaresponsetoyouremail.Oftenthesewillbecomments,whichmayrequireyoutomakechangestoyourpatch,orexplainwhyyourwayisthebestway.Youshouldrespondtothesecomments,andyoumayneedtosubmitanotherrevisionofyourpatchtoaddresstheissuesraised.Yourpatchmightbemergedintothesubsystemtree.CodethatbecomespartofLinuxisn'tmergedintothemainrepositorystraightaway-itfirstgoesintothesubsystemtree,whichismanagedbythesubsystemmaintainer.ItisthenbatchedupwithanumberofotherchangessenttoLinusforinclusion.(Thisprocessisdescribedinsomedetailinthekerneldevelopmentprocessguide).Yourpatchmightbeignoredcompletely.Thishappenssometimes-don'ttakeitpersonally.Here'swhattodo:Waitabitmore-patchesoftentakeseveralweekstogetaresponse;moreiftheyweresentatabusytime.Kerneldevelopersoftensilentlyignorepatchesthatbreaktherules.CheckforobviousviolationsofthetheSubmittingPatchesguidelines,thestyleguidelines,andanyotherdocumentationyoucanfindaboutyoursubsystem.Checkthatyou'resendingyourpatchtotherightplace.Tryagainlater.Whenyouresendit,don'taddangrycommentary,asthatwillgetyourpatchignored.Itmightalsogetyousilentlyblacklisted.FurtherinformationWorkingwiththekerneldevelopmentcommunity-theofficialdocumentationfornewkernelcontributorsHappyhacking!Thismessagewaspostedbyabot-ifyouhaveanyquestionsorsuggestions,pleasetalktomyowners,@ajdlinuxand@daxtens,orraiseanissueathttps://github.com/ajdlinux/KernelPRBot.
@nmani
I keep getting compiler errors. Someone help: $ ruby main.c > linux.exe
Did you install the dependencies with npm?
Sorrytointerruptthisfineconversation.Perhapstheresmoretothisnowhitespacenotation.verykawaii
In all seriousness, let's quit joking around.
We can't merge this on GitHub, need to make a real kernel patch and get it approved on the mailing lists.
I mean come on guys the submitter is definitely retard. Who could read the code look like a js compiled. He should read at least basics of the K&R book or read anything about C and C++ comments and empty lines as everywhere are ignored. There is no point spamming my inbox although the tread was a fun joke on a pull request submitter its annoying now. I woke up and go over 60 messages from github torvalds 437 I mean wtf guys. Stop it. :) I'm going to mute whole torvalds repo if you keep doing this on other threads. Things to do advice to all of you:
- Do some contribution to Open Source or FSF project.
- have fun outside of joking and trolling people.
- Have a life.
@jcdickinson Oh man I thought that someone who would write an explanation would at least know the difference between C and C++ code when you see it and plus the design of the programming language difference.
Sorry man you fail bad Kernel is written in C which is bad because C and every decedent of it suffers from memory surface attacks like buffer overflows, stack crashing dangling pointers just try to allocate memory outside of your stack and you get a segfault. :)
Plus the monolithic is much worse then good implemented microkernel so well we need to write or rewrite a new kernel in some functional programming paradigm language whether that is Ocaml or Rust would like to hear opinion of others on this.
And btw it is easy to write a fully functioning small kernel but to make it compatible with a lot of hardware that is a hard thing and addition of many lines in case of the Linux kernel because all of the drivers and handling of the devices in case of monolithic kernel is done inside of the kernel.
So when you see 2 million new lines in the kernel even without checking the release notes you should know that over a 90 percent of that is for device drivers and some others are for support of whether filesystems or improving in handling of some hardware and very small amount is actually focused on what the kernel is and that is memory, disk IO, CPU handling and communication in between them improvement. So anyway I just wanted to add to this ranting thread something that have more technical description :P
@mhussaincov No in C C++ and almost language built on top of them and other languages like Java like python you name it the comment lines and blank lines or ignored at the compile and or there just to improve the readability of the code.
So what you should learn is to use certain way of writing code consistently which mean if you are doing opening curly brace on the same line as the function do it like that through whole project, if you are using gnu 2 space indentation do it like that all the way etc.
And always add blank lines between functions and block comments before the important or any function that explain what it does and also for a clarification add single line comments on places where you think that you would like to clarify what the step does. And do that consistently because if you don't you might not be able to understand your code or the why you wrote it certain way a 6 months from now.
There are a lot of books on writing a source code on the proper way I mean books like How to write a good source code, and if you don't like reading books then you could read PEP8 from python which speak about similar things that are not required but recommended as a good practice to improve readability of your source code.
@jcdickinson Btw one clarification more the main difference between C and C++ is the different programming paradigm they suggest although both being general level programming languages C++ introduces the OOP concept upon C.
So the C++ is superset of you can write C code in C++ and use any of the functions and libraries of the same but you can also use C++ style and write in OOP paradigm.
Although I'm not saying that C++ have the best OOP implementation nor even that OOP is necessary anymore Bjarne in his write ups about why he made a C++ always say that he made it for his own use and later people adopted.
The main point of this is to say that C++ although being an easy language like C it actually make too many ways to do the same thing which lead to a lot of bad programming style, or bad class design and implementation. Multiple inheritance is nice and fun when you know C++ well but its really a problem if you don't know it well you make a very bad OOP design in that case Java is better and simpler for beginners as it allows only single inheritance.
The other problem of C++ the power that use of pointers in language have because dangling pointers wrong dereferencing not deleting your memory allocation once it is out of scope, which is also problem of C can lead to lot of bugs.
And actually most of the C and C++ bugs beside the bad logical implementation which would be a fault of a person who write the code is the problem with not dealocated memory or pointers that point to a wrong part of memory and make programs crashes. In other words buffer overflows and stack smashing which all lead to segfaulting or even worse if they are not properly handled by the operating system like in case of Micro$hit windblows.
This should be combined and squashed with PR #175 to reduce memory utilization
The best Greek coder @ahmetilgin Thanks for made the biggest contribution to linux!
