Incomplete directories, Kernel will not compile:"audio/Kconfig not found"; Please test what you provide about kernel HOT 24 CLOSED

You make assumptions here that are incorrect. Is it reasonable to ask the person who wrote the code to modify it for other devices considering the time it would take one, compared to the other who has to sift through it all and piece it back together to get it to function as desired? It would take you minutes; yet the logical response is develop it yourself which could take who knows how long?

I wish this only took minutes.

I'm confused as to how you reference "attitude" here, perspective is quite arguable considering your's towards anyone who asks questions, in the right or wrong place. Kernel 4.14 will develop with loire, just not with a defeatist mentality.

Rest assured this is not defeatism. The reasons have been explained to you over and over.

Has anyone inspected another sd650/msm8956 running the 4.14 kernel (is there a device)?

You are welcome to do this search yourself.

Asking other's has not amounted to anything on XDA, they all * back to @ix5 . Do you ever ask any questions || better asked, have you ever? Your perception is that I am lazy (I'll read straight through your careful typing), which I'm not; rather, it's the energy that has emmited from contacting the source that I'm questioning as even being worth the investment of mine. Nothing to do with attitude, more so to do with character.

I guess it was truly a waste of time responding to you and giving you pointers to help you solve your issue yourself instead of solving the issue for you. My bad.

As for most contributors on here, they simply followed the guides, read through the source code (including the AOSP build system) and tested/experimented a lot. And most importantly, they followed the advice they were given.

Have you started with an already working build, following the Sony guidelines? From a working system, doing small fixes is way easier. The fake treble stuff is heavily hack-ish and of course unsupported. I only did it as a tech demo.

Maybe ROM development isn't a good entrypoint for development for you. It's very complex and takes up a lot of resources. Maybe start with Android app development? That should teach you a lot of concepts you need, including git usage, before you jump into the deep cold water of device and kernel porting.
To use my Ferrari analogy: There are no tutorials on how to become a master car builder. You have to study automotive design for years, put in many many hours in the garage taking apart engines and tinkering, learn about fuel flow, torque, material wear, ...
So regular people start by working on small simple old cars, accumulate more and more knowledge, and in the end, they maybe can work on a Ferrari.
You will find lots of people helping you with simple old cars (=regular Android building). If you walk up directly to a mechanic and ask him to fix your Ferrari (complex fake treble situation) directly because you don't want to put in the hours yourself, he won't use such polite language as me. Even if maybe it only took him an hour.

Do me, personally, a favour: Don't reply to this until the day after tomorrow. Take the time to learn the basic concepts needed. Then, in case you truly get stuck, ask a question.

from kernel.

if that is the solution to when someone asks for help, then yes, everyone is busy reading books instead of writing code as there is no help to be found here for something he wrote

Hit the nail right on the head. We are spending most of our time researching what others have written in terms of documentation and code before getting a vague understanding of the system, and usually go the extra mile before giving up and asking about it instead. Intricate knowledge takes years to build up and is not something we can provide in a small github comment thread.

Hence our hints in earlier messages to see if you'd pick up on them and do the research on your own. Seeing your determination to remove techpack despite me clarifying twice removal is not the option but to look into submodules and our Android manifest shows there's very little incentive to do your own research here. I see no further questions to understand this topic either.

Broadpwn is a firmware expolit from my understanding, and I don't believe it has been patched for 4.9 kernel.

I'm asking you because you seem to be insisting on a kernel fix while at the same time mentioning it is a firmware exploit. If possible that's addressed in firmware instead of worked around with some bolt-on userspace/kernel "protections".

Pro-tip: Follow the link and [REDACTED for learning purposes].

Since everyone here knows far more than me, should I be the one answering that question?

Keep in mind we're contributing to this project in our free time, with various levels of experience and areas of expertise: we don't know everything. Me asking you the question clearly means that I don't know, right?

Kernel 4.14 will develop with loire, just not with a defeatist mentality.

Is temporarily abandoning 4.14 on legacy platforms, in favour of something way bigger called mainline, "defeatist mentality"? IMO it's called patience instead.

from kernel.

Kugo (or rather, the loire platform in general) is not supported on 4.14, see "Supported devices and functionality" - Kernel support

Please open a ticket for any further issues at the bug tracker.

from kernel.

For completeness note that techpack repositories are "submodules", but managed by our Android manifest. Building a standalone kernel for your Sony device is not that well documented anymore (read: outdated).

The same submodules apply to older kernels as well, albeit on a different branch.

from kernel.

I'm confused, why is Sony offering 4.14 software binaries for Loire and Tone? I thought the oem libraries are used in conjunction with the kernel. Since I have both of you on the topic, I could probably ask here about creating fake treble for the Loire (Kugo) family with the 4.9 kernel. ix5, your repo doesn't have loire devices nor the full tone family (keyaki specifically) included and I could not figure out how to target the compilation/build without the device included in vendorsetup.sh or whatever is in control of the devices selectable through lunch. Can you add the loire and tone device trees to your fake treble repo?

from kernel.

I'm confused, why is Sony offering 4.14 software binaries for Loire and Tone? I thought the oem libraries are used in conjunction with the kernel.

Some contributors tried to get 4.14 up and running for loire for a while, so we needed OEM binaries from Sony for porting (hen-and-egg problem), but ended up abandoning the effort for lack of time (and other devices). There was never any "official" support if you'd want to call it that.

Since I have both of you on the topic, I could probably ask here about creating fake treble for the Loire (Kugo) family with the 4.9 kernel. ix5, your repo doesn't have loire devices nor the full tone family (keyaki specifically) included and I could not figure out how to target the compilation/build without the device included in vendorsetup.sh or whatever is in control of the devices selectable through lunch. Can you add the loire and tone device trees to your fake treble repo?

I tried documenting the necessary steps in the Fake Treble article. Sorry the repo isn't buildable as of right now, lot on my plate.

Part of the learning process is not relying on turnkey solutions, so you should be able to figure out the details for loire.

from kernel.

I see that techpack has been removed, I'm assuming there is in fact an issue with it.

I'm pretty sure I already handled getting Jerplea's and your's merged correctly as I am able to target the device for a build. ODM with the 4.14 oem sw binaries (blobs) along with other modifications to the directories has been performed as per your fake treble instructions. All that's left is to build the kernel unless something else is needed within the tree. I managed to piece together the fake treble directories and files that needed modified from links local__hero provided (i.e. oem as vendor and add treble quirks, etc.) and only have a few things left to ponder: such as q_repo_update.sh && treble_repo_update.sh scripts provided from your repo are not able to be executed once the merge occurs (are these necessary to complete the kernel and vendor build?) along with the utilization of device_sony_se_policy_treble files merged into the sepolicy directory of Jerplea's (will that suffice?).

Why would there be an effort to produce binaries and not a kernel to utilize these with? There are vulnerabilities within the 4.9 binaries that were patched for 4.14 binaries. I would like to not think the 4.14 binaries and my effort so far have been shirked.

from kernel.

I see that techpack has been removed

Nope, I stated above:

For completeness note that techpack repositories are "submodules", but managed by our Android manifest.

I'm assuming there is in fact an issue with it.

Why?

ODM with the 4.14 oem sw binaries (blobs)

Keep in mind that mixing blob and kernel revisions results in a non-booting device 99.9% of the times. Since there is no booting 4.14 kernel available for Loire you'll have to pick different ODM blobs, too (those matching the 4.9 kernel you'll likely be using).

Why would there be an effort to produce binaries and not a kernel to utilize these with?

@ix5 explained just that in the comment you are replying to. Anything about that reply in particular that needs deeper explaining?

There are vulnerabilities within the 4.9 binaries that were patched for 4.14 binaries.

Any CVE in particular?

I would like to not think the 4.14 binaries and my effort so far have been shirked.

Unfortunately most efforts on older devices on a downstream kernel are futile, there will be no blob updates so you're stuck on an older kernel or attempting to hack up a solution to make these work on newer kernels. Aside from that, the more kernel upgrades we brought to old devices, the more unstable they became. If anything caused by an ever increasing number of devices we have to test and maintain concurrently.

Instead we are working to upstream these devices to the latest Linux mainline kernel, but this is a long and tedious process. In the end it means no complex, messy, manual kernel upgrades, and zero binary blobs (firmware excluded). Everything we need is open source and maintained, yet in their infancy (incomplete, certain things do not exist yet) when compared to downstream blobs.

This is why we pulled the trigger: Do we want to spend a ton of time taking all these legacy devices along with every kernel upgrade, or do we want to leave them on an older stable-ish kernel and have slightly more time to work on an actually sustainable release model?

from kernel.

Am I confused as to what is offered here: ( https://developer.sony.com/file/download/software-binaries-for-aosp-android-10-0-kernel-4-14-loire/ )? Branch 10.0.0_r15 supports the device within it's tree but the binaries are noted as 10.0.7.1, is this what you are referring to as mixing blobs and kernel revisions I am trying to build the kernel for? 4.14 binaries have the patch for broadpwn, the last 4.9 software binaries released do not as they were released prior to disclosure of the exploit.

I understand the choice to end support as there are quite a bit of devices that would need maintained and patched due to obvious variations of hardware and software/OS modifications. The drivers + blobs lack of open source alternatives are making older devices obsolete far sooner than they should be, that's my biggest gripe.

Is there a way to exclude the techpack kernel module if it is not supported for the msm8956 (Loire - Kugo) via a configuration file somewhere? Build will not complete because of the missing file(s). I understand the chances are slim to have a successful kernel built from it, but I would at least like to finish what I started and see if it does in fact boot after building the boot.img and vendor.img. If there is zero chance, then I suppose I could do the 4.9 kernel instead if ix5 (Felix) ever gets around to including a few other older devices into his fake treble tree as the current offering available for treble on this device does not suffice for 10 GSI roms (most do not boot and the few that do, do not set all the components up for use correctly). My understanding is the images must be a/b and the current treble method offered only supports a only images.

from kernel.

Am I confused as to what is offered here: ( https://developer.sony.com/file/download/software-binaries-for-aosp-android-10-0-kernel-4-14-loire/ )? Branch 10.0.0_r15 supports the device within it's tree but the binaries are noted as 10.0.7.1, is this what you are referring to as mixing blobs and kernel revisions I am trying to build the kernel for?

The binaries are offered for anyone who wants to give porting 4.14 to loire a shot. No guarantees.

Is there a way to exclude the techpack kernel module if it is not supported for the msm8956 (Loire - Kugo) via a configuration file somewhere? Build will not complete because of the missing file(s).

Yes, you could modify the kernel makefiles/kconfigs. But if you are not familiar with these concepts, I suggest you start with an already working kernel such as the 4.9 one in order to learn about kernel development. Working with a non-booting kernel is very frustrating for newcomers.

More experienced developers than you have spent considerable amounts of time and this and decided it wasn't worth the effort.
As Marijn says, mainline is the way to go. Bumping LTS revisions is a neverending game of catch-up for little gain.

I understand the chances are slim to have a successful kernel built from it, but I would at least like to finish what I started and see if it does in fact boot after building the boot.img and vendor.img.

Loire has no vendor partition.

If there is zero chance, then I suppose I could do the 4.9 kernel instead if ix5 (Felix) ever gets around to including a few other older devices into his fake treble tree as the current offering available for treble on this device does not suffice for 10 GSI roms (most do not boot and the few that do, do not set all the components up for use correctly). My understanding is the images must be a/b and the current treble method offered only supports a only images.

"Current offering"? Some guy on xda or wdym?

from kernel.

I'll revisit the 4.14 kernel after doing more research per your suggestion due to the techpack issue. The current treble offered on xda is the old method (vendor in cache) and I believe uses 9 as it's base/branch. 10_legacy uses 4.9 kernel and should be able to provide fake treble for the device. I pieced together your repo again last night, inluded kugo into the device tree, was able to target it with lunch, and now question: how do I include kugo in your q_repo_update.sh && treble_repo_update.sh to update it's make files and prepare it for build? I followed the rest of the instructions so far, so it shouldn't be too much more to get fake treble supporting 10 (& 11) GSI roms on this device like XZs already has, provided by Sjll from your (ix5) repo.

from kernel.

I'll revisit the 4.14 kernel after doing more research per your suggestion due to the techpack issue.

Leave it be for the moment. It would be like giving a Ferrari with a broken engine to someone who doesn't know how to change tyres yet.

The current treble offered on xda is the old method (vendor in cache) and I believe uses 9 as it's base/branch. 10_legacy uses 4.9 kernel and should be able to provide fake treble for the device.

Ah alright.

I pieced together your repo again last night, inluded kugo into the device tree, was able to target it with lunch, and now question: how do I include kugo in your q_repo_update.sh && treble_repo_update.sh to update it's make files and prepare it for build? I followed the rest of the instructions so far, so it shouldn't be too much more to get fake treble supporting 10 (& 11) GSI roms on this device like XZs already has, provided by Sjll from your (ix5) repo.

The q_repo_update script pulls in patches and applies them to the sodp repos so that I don't have to maintain forks. It works very similarly to the upstream repo_update script.

The issue is that I haven't rebased the patches on top of current q-mr1 branches yet. Lack of time. I'll try to update them so they are in a stable state. Then it should be easier for you to pick the patches and adapt them to loire.

from kernel.

Okay, will wait for the update on your end for loire (kugo specifically). Btw, I tired setting up the env for build and there is an error being thrown: ( device/sony/common/common-treble.mk:152: error: _nic.PRODUCTS.[[device/sony/kugo/aosp_f5321.mk]]: "hardware/broadcom/wlan/bcmdhd/config/config-bcm.mk" does not exist. ) Apparently your current loire branch (treble-odm) is missing a few things from the device tree. Appreciate the assistance here, will close this case and open on your repository under the correct branch. Thanks for the help, ix5 and MarijnS95; would be great to continue using this device with a 10 rom.

from kernel.

Updated the fake treble article to explain a bit more, see the Explanation section.

from kernel.

Okay, will wait for the update on your end for loire (kugo specifically). Btw, I tired setting up the env for build and there is an error being thrown: ( device/sony/common/common-treble.mk:152: error: _nic.PRODUCTS.[[device/sony/kugo/aosp_f5321.mk]]: "hardware/broadcom/wlan/bcmdhd/config/config-bcm.mk" does not exist. )

You can just comment out the include line. Simple fix. Please don't clutter this thread with build help talk, there's telegram groups and whatnot for that. Please keep the discussion to serious issues. We've already taken quite a lot of time out of our days to fulfill your very specific wishes.

Apparently your current loire branch (treble-odm) is missing a few things from the device tree. Appreciate the assistance here, will close this case and open on your repository under the correct branch.

That's not the "current branch". And it's not "missing" anything, you've just picked an out-of-date snapshot. Look at the ix5_repo_update repo and q_repo_update.sh specifically for the correct branches and patch revisions.

from kernel.

I've read most of the documentation and working through git is a maze at times. The current branch is master here at SonyXperiaDev, correct? Am I to instruct q_repo_update to inlcude the branches treble-odm, kernel-path, and disable-verity* ? I have not the slightest clue how to cherry pick commits, and if I have to modify the script q_repo_update to use the device-sony-loire tree from SonyXperiaDev I will be lost as there are quite a few (467, am I supposed to include them all, why wouldn't the tree just be updated automatically with the modifications?) As for removing the include, I assume you mean within the f5321.mk file, but apparently I am using the wrong branch already so I will have to scratch that.

Originally my question as to why the kernel would not compile spawned this discussion, as fake treble is the end result of what lead me here to begin with. I read through your documentation and it is met with apprehensiveness to any questioning. Figured, even though it's now off topic, this was the best place to ask. There is not a telegram group for X & X Compact (Loire), so where else should I be seeking guidance? Apologies for any time you feel has been wasted, it hasn't been and you might see it as that in retrospect.

Let me ask one other thing, you speak of automobiles as if it is a passion or hobby. Do you know how to work on those too; if so, was someone there to teach you about it intially or did you come out the woom with a complete set of tools and as a master of mechanics? Food for thought, the basis for everything you know has been handed down from someone else, a vine of knowledge metaphorically speaking. You seem to have the passion to share what you know, mixed with a frustration that appears somewhat jaded. I get it, it's (development) frustrating with very little reward - there's always something better - and contentment is short lived.

I'm sure there is something I can share in return, but that isn't really for this github comment section nor was my response. Thanks for sharing what you can.

from kernel.

@1m0g Sorry, wasn't paying attention to the kernel issues, hence missed the conversation.

If you are interested in compiling Android 10 for Kugo/Loire you might want to check here: sonyxperiadev/bug_tracker#536

I myself have a kugo running with Android 10 and Kernel 4.9. It is OK, but has its issues.
Regarding future updates: I updated kernel 4.9 till .230, but without dev help, couldn't solve the merge issues in the following releases. hence it is stuck there.
Haven't tried Android 11 and probably will not try, as my Kugo nears its end.

from kernel.

@chris42 ,

I read through your development thread/bugtracker#536 and believe I know what might be causing issues with the kernel, which would be oss. Is it possible to change the audio driver/module to alsa? I have similar issues with 4.9 on 9 with the audio and it is usually caused by some sort of policy/device switch that audio is being handled through, i.e. playing music through speaker and then plugging in headphones; rather than if I start an audio stream after boot, such as plugging in the headphones before the stream the app generates, and then starting the app. So - theory is audio driver is the culprit. Sort of what lead me here to begin with. I was having an issue compiling the 4.14 kernel due to an error during build stating that techpack was missing Kconfig in the audio directory, which in my case neither existed from the repo I was syncing from.

What I am trying to do is a bit different though in comparison to your project, which is fake treble booting a 10 GSI and beyond with a mostly stable device. Current fake treble provided lacks the option of anything above a 9 GSI (using vendor in cache, instead of ix5's method which needs a bit more work to function for loire devices).

from kernel.

I've read most of the documentation and working through git is a maze at times. The current branch is master here at SonyXperiaDev, correct?

If you want to use AOSP master, you should use sonyxperiadev master. But you most likely want to build Android 10, so q-mr1 makes more sense.

Am I to instruct q_repo_update to inlcude the branches treble-odm, kernel-path, and disable-verity* ?

No. The script already picks the right patches. You need to adapt the patches to loire. Also, there are not only three patches. Those are just the ones I chose as examples so you could understand what the script is doing.

I have not the slightest clue how to cherry pick commits, and if I have to modify the script q_repo_update to use the device-sony-loire tree from SonyXperiaDev I will be lost as there are quite a few (467, am I supposed to include them all, why wouldn't the tree just be updated automatically with the modifications?)

Then you should learn how to use git first. It doesn't make much sense to jump right into advanced usage when you're lacking the basics.
A good resource I can recommend is Git Immersion. Also https://try.github.io/, https://www.atlassian.com/git, https://agripongit.vincenttunru.com/

As for removing the include, I assume you mean within the f5321.mk file, but apparently I am using the wrong branch already so I will have to scratch that.

Please look for where hardware/broadcom/wlan/[...].mk is being included from, either in device/sony/loire or device/sony/kugo. You can use grep -R to search in all files inside a repo. Show a little initiative instead of being spoon-fed, please.

Originally my question as to why the kernel would not compile spawned this discussion, as fake treble is the end result of what lead me here to begin with. I read through your documentation and it is met with apprehensiveness to any questioning. Figured, even though it's now off topic, this was the best place to ask. There is not a telegram group for X & X Compact (Loire), so where else should I be seeking guidance? Apologies for any time you feel has been wasted, it hasn't been and you might see it as that in retrospect.

There are thousands of people on xda-developers or in telegram groups (e.g. android building help) willing to help newcomers. There are so many tutorials out there teaching the basics.

But if you want experienced developers to answer your questions, you need to be prepared. If you know you will need to learn git, android makefiles and concepts such as fstab etc during your development, you need to learn about them before wasting other people's time with basic stuff. We're not your sensei who will teach you everything.

Let me ask one other thing, you speak of automobiles as if it is a passion or hobby. Do you know how to work on those too; if so, was someone there to teach you about it intially or did you come out the woom with a complete set of tools and as a master of mechanics? Food for thought, the basis for everything you know has been handed down from someone else, a vine of knowledge metaphorically speaking. You seem to have the passion to share what you know, mixed with a frustration that appears somewhat jaded. I get it, it's (development) frustrating with very little reward - there's always something better - and contentment is short lived.

It's about the attitude. We enjoy helping people who take some effort to apply our guidance and search for answers themselves.
By the way you ignored our advice

• about 4.14 not being reasonable for loire
• about Kconfig (you didn't bother looking up what it does)
• about submodules
• about cherry-picking git commits (you complained that you didn't know how git works instead of taking 1-2 days to learn it)
• about the correct git branches (it says which branch is used right inside the q_repo_update script)

we can only assume "helping" you would result in even more questions that you could have answered yourself.

People telling you to RTFM don't want to belittle you but want you to learn for yourself.

from kernel.

You make assumptions here that are incorrect. Is it reasonable to ask the person who wrote the code to modify it for other devices considering the time it would take one, compared to the other who has to sift through it all and piece it back together to get it to function as desired? It would take you minutes; yet the logical response is develop it yourself which could take who knows how long? I'm confused as to how you reference "attitude" here, perspective is quite arguable considering your's towards anyone who asks questions, in the right or wrong place. Kernel 4.14 will develop with loire, just not with a defeatist mentality. Has anyone inspected another sd650/msm8956 running the 4.14 kernel (is there a device)? Asking other's has not amounted to anything on XDA, they all * back to @ix5 . Do you ever ask any questions || better asked, have you ever? Your perception is that I am lazy (I'll read straight through your careful typing), which I'm not; rather, it's the energy that has emmited from contacting the source that I'm questioning as even being worth the investment of mine. Nothing to do with attitude, more so to do with character.

from kernel.

Seriously, do you reflect on who you are in words? You've got this big macho mouth, but I doubt you fill the role. You also keep referencing automotives as if you are a mechanical engineer; it's funny how well an engineer can actually fix their own car, I've witnessed this myself, and a lot of their knowledge has oversights or else there would be no need for new models, year after year, just new parts from wear. I doubt you even know how to work on your own car. Your emotional IQ is at the beginning of the curve if you follow an axis correctly here. Getting angry and stating you've explained things "over and over" is not actually accurate. The kernel was abandoned you stated, that doesn't mean it can't be fixed. Your analogy of cars and how they operate would apply to a piece by piece diagnostic of the kernel, which I agree it does take quite a bit of time depending on the culprit. Don't respond until the day after tomorrow, because you insult other's with your inflated ego and get a kick out of it is the end result of the social stance you decided to take, why - well, I already answered that reading who you are. No wonder things are so slow here with development for Xperia devices, personalities sure add to the productive environment.

from kernel.

Getting angry and stating you've explained things "over and over" is not actually accurate. The kernel was abandoned you stated, that doesn't mean it can't be fixed.

Nope. We are missing critical blobs that make us unable to continue. But then again we have decided it's not worth it, when we can lock our efforts in for the future by spending time on mainline and open-source, cross-device and cross-vendor compatible solutions (mainline kernel, mesa, etc).

No wonder things are so slow here with development for Xperia devices

Funny how you suddenly have to insult the entire community here 🤔 . Passive-aggressive title yet lacking a single tangible issue that can actually be worked on. On that note, have you figured out what a submodule is yet?

from kernel.

4.14 binaries have the patch for broadpwn, the last 4.9 software binaries released do not as they were released prior to disclosure of the exploit.

Have you checked whether this fix resides in firmware, userspace binaries (afaik we don't have any since switching from bcmdhd to brcmfmac) or the kernel?

• If firmware: https://github.com/sonyxperiadev/vendor-broadcom-wlan
• If kernel: the fix is likely backported to 4.9 and applied already.

from kernel.

@MarijnS95 ,

It's not everybody I'm directing the comment at, just ix5, who's help on documentation he has provided is go read a library of books and get back to me (if that is the solution to when someone asks for help, then yes, everyone is busy reading books instead of writing code as there is no help to be found here for something he wrote). Doesn't seem very helpful or friendly, can only imagine working on a project with him. I know, he posted some informative links, but I can read the code for the most part and piece together how the commands in the files work. Somethings just aren't fully clear. Apparently, I am not that proficient at the moment with navigating AOSP via Github, along with needing to brush up on a few Linux commands - my apologies. I think what I was asking was simple enough for him to put together for other's (not just myself) in a short amount of time.

Broadpwn is a firmware expolit from my understanding, and I don't believe it has been patched for 4.9 kernel. Since everyone here knows far more than me, should I be the one answering that question?

Passive-aggressive: not in the least, I ask questions and am pretty much told to go away and figure it out myself. The answers provided were not clarified until further questions were asked. There are other variables left to be solved when gaining knowledge of how something works or doesn't for this matter. I confront rather than sidestep. Your native langauge is not english, so I'll simply perceive it as a barrier of transmission as to what you truly meant. Expression of frustration at someone and then told they are the aggressor is a bit socially distorted. Is it my fault that I don't fully understand the architecture & code - yes (sort of); is it my fault that someone gets mad at me for asking questions so that I may better understand and learn - no.

from kernel.