| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <46934821.5020409@gmail.com> Date: Tue, 10 Jul 2007 17:49:37 +0900 From: Tejun Heo <htejun@...il.com> To: Cornelia Huck <cornelia.huck@...ibm.com> CC: Alan Stern <stern@...land.harvard.edu>, Kernel development list <linux-kernel@...r.kernel.org> Subject: Re: Sysfs and suicidal attributes Cornelia Huck wrote: >> I like it because it shifts complexity from the drivers into driver >> core. IOW, the driver model is kinder to drivers that way - the driver >> writer doesn't have to care whether something is suicidal or not - and I >> think that's the way we should be headed although we're not good at it yet. > > It might be that I misunderstand the idea, but doesn't the device > driver writer need to consider whether the attribute is suicidal as > well? (If it is the method that needs to call the sysfs core.) What I was trying to say was that suicide and murder could be done the same way from the driver's POV or am I misunderstanding? > A general immediate disconnect of the buffers (which will be handled in > a second pass) would be great, but doesn't sound easy. I haven't thought too hard about actual implementation but it's pretty specific case. If doing things in generic manner is difficult, there are plenty of shortcuts to choose from, I think. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists