[HN Gopher] Kernel developer write a USB driver in 3h for Apple ...
___________________________________________________________________
Kernel developer write a USB driver in 3h for Apple Xserve front-
panel [video]
Author : explosion-s
Score : 143 points
Date : 2024-05-26 17:28 UTC (5 hours ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| cm2187 wrote:
| Not quite from scratch...
| maxlin wrote:
| This. Why use the the explicit term "from scratch" when it's
| not even closely true.
| walterbell wrote:
| Does anyone write a new kernel driver without using reference
| code for the Linux kernel subsystem? The code is less
| interesting than the human commentary. Imagine future AI-
| simulated "coding commentary".
| birdiesanders wrote:
| This sounds truly dreadful.
| walterbell wrote:
| Indeed. How can today's developers avoid their Twitch
| streams being used to train future commentary-pollution
| LLMs?
| Am4TIfIsER0ppos wrote:
| You mean he didn't invent the universe? (Thanks to Carl Sagan)
| dang wrote:
| Ok, we've scratched that bit from the title above.
| dgellow wrote:
| I dreamed of that type of content since I've been a teenager.
| Thank you for sharing, it's fantastic to see more and more
| programmers streaming themselves working on fairly advanced
| projects. That removes so much layers of magic and complexity
| once you can peek behind the curtain this way
| logrot wrote:
| I envy kids today to be able to look up pretty much anything
| what they want to learn. It was not like that back in the day.
| seanthemon wrote:
| Alternatively, our routes back in the day was relatively
| linear, whereas today kids have to wade through so much more
| to find their paths
| explosion-s wrote:
| I just wrote out a reply to the parent comment about
| learning to code but forgot to reply to this one, my
| previous comment is here:
| https://news.ycombinator.com/item?id=40484956
| explosion-s wrote:
| I (not the programmer in the video) started programming 2
| years or so during the pandemic during sophomore year of high
| school. I can affirm - there is a lot to wade throughm it's
| hard to know what's relevant, easy to learn and useful in
| real life.
|
| That said, despite the availability of content online I tend
| to only watch the videos where something is a) summarized or
| b) something very advanced is broken down (e.g. the micro-gpt
| from scratch series). Imo, the best way to learn programming
| is to get excited about bringing your ideas to life, and
| choosing ideas small enough (at the start) to accomplish.
|
| I am worried though about the rise of machine learning which
| may increase the barrier to entry in industry jobs and
| require more expertise to get ones "foot in the door".
| Additionally I find it hard to resist learning new
| technologies that are not as widely used / changing quickly
| do to their ease of use (Svelte, Tauri, V lang, etc).
|
| Anyways, just thought I'd chime in as a kid learning to code
| brailsafe wrote:
| > Additionally I find it hard to resist learning new
| technologies that are not as widely used / changing quickly
| do to their ease of use (Svelte, Tauri, V lang, etc).
|
| One thing I'd suggest is to be somewhat critical of what it
| means to be learning something, and find a way to apply
| whatever that is multiple times, without spreading yourself
| too thin.
|
| When I was getting started around the same age, I never
| bothered repping things out like at a gym or going deeper
| into how things worked and piecing them back together
| manually from scratch (such as the micro-gpt project), but
| those are two ways you can keep things interesting long
| term, and develop useful/practical knowledge. Instead, what
| I did was read a book or follow a tutorial and figured that
| was enough to learn, but it's often just what was possible
| to teach, or a good jumping-off point, and that's basically
| what I've been getting from GPT lately. Nothing really gets
| learned imo unless there's an input and output to the
| process, such as watching the video and writing all the
| code from scratch or on paper, and then hopefully building
| something with it where you'll be forced to push yourself
| mentally. Very little of the depth might apply in a job,
| but you'll be better at troubleshooting and understanding
| what's happening, and repping out gradually more abstract
| and complex projects using the same technology will make
| you more efficient. Especially with ADHD that I didn't
| realize I had earlier, it would have really helped to rep
| things out more, because only through repetition and
| expanding complexity do you understand the gritty bits that
| aren't complete, or areas where you're likely to need
| another tool, or useful shortcuts and edge cases etc..
|
| Incidentally, NAND2TETRIS is a great example of an end to
| end course that is totally worth trying and slowly grinding
| through.
| NegativeLatency wrote:
| > I find it hard to resist learning new technologies that
| are not as widely used / changing quickly do to their ease
| of use
|
| This isn't a bad thing. I've never regretted trying
| something new, even if it's just to learn that I don't like
| it or whatever. "normal" software engineering stuff (day to
| day) is so much more about building and maintaining what
| you have already.
| vdfs wrote:
| The most interesting thing to me is that font for a
| terminal/coding
| CasperH2O wrote:
| And no color highlights either!
| shaicoleman wrote:
| Font is Comic Code
|
| https://tosche.net/fonts/comic-code
| penguin_booze wrote:
| No line numbers, either!
| GauntletWizard wrote:
| As much as I love this kind of video, a deep dive tutorial, "from
| scratch" is kind of a misnomer. "From 10 years of experience
| doing exactly this" doesn't have the same ring
| asadm wrote:
| Not sure why everyone is stuck on "from scratch" part. This is
| from scratch in all practical terms to me. They would be wasting
| their and viewer time if not done this way.
| userbinator wrote:
| Because there are us who have actually done USB device drivers
| "from scratch", i.e. using the specs or gone through the RE
| process for an unknown device, while this is basically porting
| existing code to a new API. Thus it's rather clickbaity.
| amelius wrote:
| The USB spec is like, what, 500 pages? That is impressive.
| tedunangst wrote:
| I couldn't even transcribe 500 pages in three hours.
| bartvk wrote:
| You don't need to read the nitty-gritty of the USB spec itself,
| having a general idea of its capabilities is enough. The kernel
| gives you a bunch of functions to work with. You can learn it
| by simply reading the code of the most simple driver that you
| can find in the kernel source. Then you can step up, and find a
| more difficult one.
| pantalaimon wrote:
| A good driver API will hide that all and make sure an
| individual USB driver does not have to care about the USB spec
| - that's the job of the shared USB core code.
| userbinator wrote:
| ...after numerous more hours of understanding how things work.
|
| Not mentioned in this title is that this is a USB _device_
| driver, for a relatively simple device, with existing code
| available. This is essentially a code-to-code "translation"
| task. I can see how this looks very impressive, but IMHO it's
| like watching anyone else skilled at their profession.
| explosion-s wrote:
| > ...after numerous more hours of understanding how things
| work. > > Not mentioned in this title is that this is a USB
| _device_ driver, for a relatively simple device, with existing
| code available. This is essentially a code-to-code
| "translation" task. I can see how this looks very impressive,
| but IMHO it's like watching anyone else skilled at their
| profession.
|
| Yeah - the title is a little off. My apologies! I'm not super
| knowledgeable about the kernel myself and while I did gain some
| knowledge from watching the video a lot of it looked like pure
| magic.
|
| If a mod wants to edit the title to remove the "from scratch"
| and add that it's a device driver that would be great but
| otherwise, no worries
| dang wrote:
| Done. Thanks for the interesting submission!
| stefan_ wrote:
| One that barely has a reason to exist, a front panel is
| probably better served being managed by some libusb application
| in userspace..
| debo_ wrote:
| The loud sound of fans whirring in the background is the perfect
| ambiance for this video!
| dcan wrote:
| I wrote a USB host driver for the STM32F4 a couple months ago,
| and the most difficult part was the lack of good documentation -
| the peripheral had r/w registers mapped as read-only in the SVD,
| there was a bit you had to set that wasn't mentioned in the
| documentation, and then the whole USB bulk-only-transport
| pointing to a non-existent SCSI spec. I ended up finding a blog
| post stating that you have to basically copy what Windows does in
| order for USB drives to work.
|
| Luckily I had an oscilloscope that could decode USB frames to
| save me a whole bunch of time to understand why things weren't
| working.
|
| USB seems to depend on a whole lot of tribal knowledge, which
| makes it impressive that it is so ubiquitous and works out of the
| box for the most part.
| raggi wrote:
| Intel USB controllers are extremely forgiving of control
| software bugs. Extremely
| dayjaby wrote:
| May I ask which oscilloscope you used for USB decoding?
| jonhohle wrote:
| I started contributing to a decompilation project and while I'm
| not the best decompiler by any stretch of the imagination I've
| thought about streaming while I'm working.
|
| Is there interest in content like this? Are people curious about
| tells for when assembly is affected by variable sign, struct vs
| array access, the bonkers things even 30 year old compilers do
| with control structures, register reuse, etc. and how to coax
| code into byte equivalent assembly from classic consoles.
| 0x303 wrote:
| Made an account to say yes, this would be awesome to watch.
| I've been trying to accumulate esoteric reversing knowledge
| like this but it's hard to know where to even look!
| khazhoux wrote:
| I wonder if this video is painful to watch for people who claim
| "10x programmers are a myth!"
|
| As an eng manager who's overseen teams at several top FAANGs, I
| can say without a doubt that most of those engineers would have
| taken 1-2 months to implement a driver.
| epcoa wrote:
| This is confusing lack of experience with a specific discipline
| with productivity.
|
| If you have the specialized knowledge, you'll know that
| "writing a driver" is an overloaded term to start.
|
| This guy isn't going from a blank slate "scratch" either. There
| is tremendous amount of boiler plate being started with (in
| addition to the tremendous amount of core driver and USB
| "library" code in the base kernel)
|
| And for those with experience in writing device drivers nothing
| here is super human or even not mundane. This is a well
| documented (existing code) hardware with a simple interface. If
| you're already experienced with Linux kernel device drivers,
| this is not a terribly complex incremental task.
| raggi wrote:
| Yup, scanned through the video, I don't think the guy
| authored a single function, just grabbed skel and parts from
| other code bases, deleted stuff he didn't want and fixed a
| little glue and build code
| Rinzler89 wrote:
| Exactly. Plus, the author is not totally new to this.
| According to his resume he's been writing drivers since the
| late 90's so this probably isn't his first rodeo. He makes it
| look easy.
| stavros wrote:
| No it isn't. Most programmers just don't have the experience,
| and don't much care to get it. I've long thought 10x
| programmers were a myth, until I saw how much faster some of
| our developers are compared to others. It's pretty close to
| 10x, some people will do something in a week, someone else in
| half a day.
|
| The person who did it in a week wrote a thousand lines of
| terrible code, the second person replaced it with fifty
| lines.
| bboygravity wrote:
| If you ask me to code something that I worked on during my
| last project/client, I'll probably do it more than 10x
| faster.
|
| My point: one person can be his own 10x coder depending on
| (recent) experience and niche knowledge being applicable to
| a project. To any manager I will look more than 10x faster
| than my peers.
|
| But I would definitely not be 10x "better" than my peers at
| our job in general.
| stavros wrote:
| So you're saying that the people who've been with us for
| years that do things 10x faster than their peers did the
| same things last month?
| sibit wrote:
| I don't think you can compare the productivity of someones
| passion with someone who's writing code they're told to write
| at a job.
| moritonal wrote:
| I have to point out that if you're the consistent factor over
| all these seemingly mediocre engineers, then that really might
| say more about the manager roasting their own employees on a
| public forum than them?
| Rinzler89 wrote:
| IDK, but isn't it public knowledge already the everyone goes
| to work at FANGs to "rest and vest"?
| foldr wrote:
| You have to look at the total time (crucially including future
| maintenance and bug fixes) not just the time to get to a basic
| working prototype.
___________________________________________________________________
(page generated 2024-05-26 23:00 UTC)