Re: BPF memstore and bpf_validate_ext()
Mindaugas Rasiukevicius wrote: > Alexander Nasonov wrote: > > My point is that you mix "argument pack" with something else. They > > should be separeted. > > The external memory store can be used as an argument (and the initial > values determined as proposed in this thread). If you want, we can pass > it as a third argument, I just think it is a pointless indirection level. > Would even need extra wrapping i.e. more work in bpfjit, but if you want > that separated - fine. I'll tell you more. Mixing mem with arguments will not only save me one register/one indirection level but it will allow to use memory addressing. It's very attractive solution from a performance perspective. But it's clearly a hack and I don't want to have hacks in public API. > > I already offered to support SLJIT_FAST_CALL copfuncs in bpfjit. > > They're much faster than regular copfuncs. But that's mean you > > will need to emit sljit code and you will have a limited number of > > sljit registers and all other limitations of sljit. You still should > > be able to copy data from auxiliary argument to memstore and you > > can do it quite fast. <...> > > That is great, but we are going circles here. If a program just needs > some values stored in the memory store - why would you create a COP to > get few integers instead of simply letting the caller to pass them. It > is the thing which actually has those numbers. What if your program "just needs" something else? Does it mean we have to add a new feature to bpf? No. We have to stop somewhere. BPF_COP is powerful enough for getting external data. It's a bit slower but I can give you SLJIT_FAST_CALL interface. If it's still slow for you, you should stop using sljit and consider other alternatives. > > It's easy to > > suggest to have a flag but it's actually a lot or work. You need to > > write several lines of C code to generate a single instruction. > > The flag would basically say "treat the memstore as internal i.e. just > do all the optimisations, because I assure there are no side effects". > It is a green light for what you said you already want to implement. > That would be one-liner check or I miss something? Ok, with my recent change on github, it's indeed one-line change but having two different modes can introduce subtle bugs. If you forget to set the mode properly, you may have a situation when your memory is in a bad state only for packets of length 131 (or whatever) and it's consistent for all other lengths. I'm as a maintainer of bpfjit is responsible for a robust public interface. Alex
Re: Porting Linux SCSI ioctl stuff (was: Re: LTFS)
On Wed, Dec 18, 2013 at 03:34:31PM +, Emmanuel Dreyfus wrote: > > With sensedata defined as: unsigned char sensedata[128] > > What does that mean? i woudl have expected to have buffer > lengths at the same size. > Sounds like someone is not following the scsi specification. -- Brett Lymn This email has been sent on behalf of one of the following companies within the BAE Systems Australia group of companies: BAE Systems Australia Limited - Australian Company Number 008 423 005 BAE Systems Australia Defence Pty Limited - Australian Company Number 006 870 846 BAE Systems Australia Logistics Pty Limited - Australian Company Number 086 228 864 Our registered office is Evans Building, Taranaki Road, Edinburgh Parks, Edinburgh, South Australia, 5111. If the identity of the sending company is not clear from the content of this email please contact the sender. This email and any attachments may contain confidential and legally privileged information. If you are not the intended recipient, do not copy or disclose its content, but please reply to this email immediately and highlight the error to the sender and then immediately delete the message.
Re: Porting Linux SCSI ioctl stuff (was: Re: LTFS)
On Thu, Dec 12, 2013 at 05:58:53AM +0100, Emmanuel Dreyfus wrote: > NetBSD counterpart seems to be SCIOCCOMMAND I got it building, but it fails when talinkt to the drive. It is probably caused bu sense field in struct scsireq: it is SENSEBUFLEN long at maximum, whish is 48 bytes. Linux code fills up to 128 bytes in the counterpart: sg_io.mx_sb_len= sizeof(scsi_io->sensedata); sg_io.sbp = scsi_io->sensedata; With sensedata defined as: unsigned char sensedata[128] What does that mean? i woudl have expected to have buffer lengths at the same size. -- Emmanuel Dreyfus m...@netbsd.org
