I recently had to route a PCB for a fpga using DDR3. It needed 3 designs to get the ram interface good. Dont get me wrong i have designed such things before but there are so may external factors. Now think of DDR of higher order. I think they are on the edge what can be done on todays PCB design
I once had a antenna with a lamp on it. It was used to detect best place for the radio. It just rectified the energy it received and used a very tiny light bulb
Indeed, the project has gone through a few iterations already (It was first a monolithic kernel module that required a secondary module to call into the API and whatnot). I've went towards a more userspace-friendly usage mainly so that you can iterate your changes much, much faster. Creating the synthetic PCI device is as easy as opening the userspace shim you program, it'll then appear on your bus. When you want to test new changes, you close the shim normally (Effectively removing it from the bus) and you can do this process as many times as needed.
Hi, thanks. That's almost it. The remaining problem is just how to tie it together (where do I put the handle_mmio_read pointer or which event should it be handled in?)
PCIEM_EVENT_MMIO_READ is defined but not used anywhere in the codebase
Hi! Sorry, this is an issue on my side; I forgot to update the documentation's example with the latest changes.
You basically have the kernel eventfd notify you about any access triggered (Based on your configuration), so from userspace, you have the eventfd and then you mmap the shared lock-less ring buffer that actually contains the events PCIem notifies (So you don't end up busy polling).
You basically mmap a struct pciem_shared_ring where you'll have your usual head/tail pointers.
From then on, on your main, you'd have a select() or a poll() for the eventfd; when PCIem notifies the userspace you'd check head != tail (Which means there are events to process) and you can basically do:
The documentation still refers to PCIEM_EVENT_MMIO_READ but it's never referenced in the code on the main branch
I'll admit that I asked for a simple compilable example illustrating something simple like the read events because it looks like it's just reading from the shared memory, and maybe generating an event for any read or write access with the PCIEM_EVENT_MMIO_WRITE event type
PCIEM_EVENT_MMIO_READ is kept for reference on the while (head != tail) loop just to remind the user that there can be more than 1 event registered in terms of access type.
Let's say that you register your watchpoint in READ mode (I still have to change the IOCTL for that as currently is hardcoded for writes: attr.bp_type = HW_BREAKPOINT_W), then you'd be consuming PCIEM_EVENT_MMIO_READ events instead of PCIEM_EVENT_MMIO_WRITE.
The fact that the PCIEM_EVENT_MMIO_READ define is there is to help me remind me to incorporate that missing logic.
Could you explain in layman terms how it would help with developing PCIE hardware / drivers? I can immediately imagine something like writing more robust unit tests and maybe developing barebones drivers before you get access to actual hardware, but that's where my imagination runs out of fuel.
Sure! Let's say you (Or the company you work for) are trying to develop an NVME controller card, or a RAID card, or a NIC...
Usually, without actual silicon, you are pretty limited on what you can do in terms of anticipating the software that'll run.
What if you want to write a driver for it w/o having to buy auxiliary boards that act as your card?
What happens if you already have a driver and want to do some security testing on it but don't have the card/don't want to use a physical one for any specific reason (Maybe some UB on the driver pokes at some register that kills the card? Just making disastrous scenarios to prove the point hah).
What if you want to add explicit failures to the card so that you can try and make the driver as tamper-proof and as fault-tolerant as possible (Think, getting the PCI card out of the bus w/o switching the computer off)?
Testing your driver functionally and/or behaviourally on CI/CD on any server (Not requiring the actual card!)?
There's quite a bunch of stuff you can do with it, thanks to being in userspace means that you can get as hacky-wacky as you want (Heck, I have a dumb-framebuffer-esque and OpenGL 1.X capable QEMU device I wanted to write a driver for fun and I used PCIem to forward the accesses to it).
this article showes very nice what i do not like in modern c++. Packing easy concepts like lifetime and ownership of data behind complex generic named classes. don't get me wrong; i still like OOP, i even use OOP in c (wel OOP like code) but i do not like the concept of packing easy things in complex ones. perhaps im a litte old :)
as i already wrote in an other comment. Where are the millions lines of code needed to train LLM in this Nanolang? LLM are like parrots. if you dont give them data to extract the statistic probability of the next word, you will not get any usefull output. LLM do not think, they can't learn without training data
That's an incorrect assumption. You can get quite far with some skill documents and some examples in combination with tools to compile and run your code. The LLM will train itself on the fly based on the feedback from these tools.
Im not in web development. Reading this article makes me think: is it realy neccersary to use all those complex frameworks? Isn't html/css enough? People always say "every line not written can't be a bug" but moving those lines into a library was not the idea behind the words
No, obviously. If you are writing complex web applications with state, local processing of data and asynchronous interactions it's not enough. You need javascript. If your javascript is especially complex and you desire it to be declarative, you probably need a framework. Do you need, I don't know, Tomcat in Java? Probably yes for a complex application and no for a simple proof of concept. Do you need a database? Aren't files enough? And so on.
Shadcn is a framework for developers who develop highly interactive web apps. If all you need is a static form that submits data to a web service, you probably don't need a framework (except when you need it - for example, selects are not yet fully styleable in all browsers).
Next objection usually is: do you need complex apps on the client? Can't they be reduced to a series of simple forms controlled by the server? Sometimes they can and sometimes they can't, but of course I will decide the shape, behaviour, complexity and look of the applications I build (or have others build for me), thank you very much.
That said, radio buttons have been styleable in all non-legacy browsers for at least 5-6 years, there's no excuse for rewriting them from scratch with svgs.
>If you are writing complex web applications with state, local processing of data and asynchronous interactions it's not enough.
>Next objection usually is: do you need complex apps on the client?
It's not even an objection, it's a question I ask and almost never hear a coherent answer to. The vast majority of web applications I use every day (online banking, github, forums, social media, admin interfaces of various developer tools, etc.) don't really need to be dynamic and frontend-rich. I don't care if submitting a form refreshes the page. Funnily enough, full page refresh with a full round trip with "old school websites" is often faster than dynamic SPA interaction.
I don't care that when I click "delete", the item may not disappear from the screen immediately. I don't want to see some in-between state descriptions like "Deleting..." because I know it's a lie in a distributed, eventually consistent system. Just tell me the truth: the request has been sent. I can then refresh the page and see the new current state, whatever it is.
I really don't understand this desire to make websites behave like local apps while in reality they aren't.
> it's a question I ask and almost never hear a coherent answer to.
There are a lot of coherent answers though.
One is that responding with HTML encumbers the server with brittle UI over the wire when it could instead be a simpler API server that any client can talk to.
Returning data instead of UI from the server is a clean separation of concerns.
That's the theory. In practice, if your UI is changing a lot, the data your UI needs is also changing a lot, meaning that your data API will either have a lot of churn or you'll allow a lot of flexibility in how untrusted clients can use it, which introduces it's own pile of issues.
> I don't care that when I click "delete", the item may not disappear from the screen immediately.
The disconnect here between tech people and non-tech people is that most users do care about stuff like this.
I run a popular website as a solo project so all the feedback/complaints are routed to me, and one thing I've learned is that users really don't want websites to "feel old". Sure, they want it to be fast, but they also want all the bells and whistles like loading indicators and animations.
If you show Hacker News to someone who's not a developer, especially if they're under 30-35, their reaction to the layout and functionality will be visceral disgust. I really can't stress enough how much modern users hate the traditional plain HTML look. If you're trying to convince users to use your site and it looks or functions anything like HN, they'll get angry and close the tab within seconds to look for an alternative. Even if you've made a SPA with plenty of bells and whistles, users will still get upset if anything feels "clunky", which is often user-speak for "this component needs animations and a transition state". They don't know or care that all the fancy stuff increases the complexity of the codebase.
Every software project hits a point where the super clean abstractions the developers came up with start to clash with the messy way it's used in the real world. This is the frontend version of that. We have no choice but to give users the UX they want.
> I really don't understand this desire to make websites behave like local apps while in reality they aren't.
Since the dawn of time, humans have sought to eliminate mushy laggy UIs, such as having to wait for a full page reload whenever you click a button. I don't like SPAs either, but dunno, I don't find it particularly hard to understand how we got here.
Immediate feedback informs the visual language in order to convey meaning in a easier way to a larger public. You may know what an eventually consistent system is, but many users don't, and they want visual information abstracted to something they can understand. It's reassuring.
Also, not everything can be reduced to static forms. Charts with knobs, drag and drop interfaces, interactive diagrams are all useful visual aids that you would like to erase because... they don't conform with your naive views on how things should look like?
That’s why I use React, though. It’s much nicer (as a developer— not necessarily UX) to have a single paradigm and approach to building your app vs using one approach for the simple pages and a different approach for the handful of highly interactive pages. Inevitably, your simple pages get complex interactive edge cases and you wish you’d written those in React from the start, etc.
I know many will disagree with me and will point to livewire, etc as alternative approaches, and that’s valid. I’ve simply settled on React because it fits my mental model, I like functional programming, and I dislike that bifurcation problem.
No, you're right. Livewire, Phoenix LiveView and all the others are a couple levels removed from the browser and you have to suffer the whole indirection chain when something goes wrong. React is a good compromise - it still has indirection, but not so much, and it's much easier to use at scale than state managing and direct DOM manipulation.
A lot of frontend developers today (my experience) does't even know where to look for CSS updates or what vast amount of HTML element exists, they just know to look for frameworks and that's how they see the world.
Like <input> is foreign to them, they only know of <FrameworkTextComponent>.
Sometimes you do need a framework, but the question is being asked way too seldom.
If you're not into web development, Hacker News discussions about React are really bad way to gain unbiased perspective - it's been really popular here for last few years to just hate React (usually they know nothing, e.g. anyone who claims hooks compose worse than class components). But there's a reason why React is still used the most (large ecosystem, fast development and backwards compatibility). Of course, it's easy for inexperienced developer to produce slow and buggy apps (maybe slightly easier than in other frameworks, but that's practically unquantifiable), to include unnecessary or even badly written dependencies, etc. - but it's not the tool's fault when it's being used incorrectly.
i realy hate it when well knowen world like "temperature" are missused to discribe something complete out of context. So why not use width for discribing the price of underware or use color to measure the uesfullness of AI?
reply