On Thu, Jan 29, 2015 at 2:37 PM, Greg KH g...@kroah.com wrote:
On Thu, Jan 29, 2015 at 01:11:13PM -0500, David Legault wrote:
Hello,
I'm working on some linux kernel driver stuff and I have a fake path
called /
dev/blah/whatever that points to /dev/block/real_device.
That's a
Nice, thank you
30.01.2015 18:24 пользователь Malte Vesper
malte.ves...@postgrad.manchester.ac.uk написал:
Spinlocks imply memory barriers as far as I am aware...
Read here: http://lxr.free-electrons.com/source/Documentation/memory-
barriers.txt#L1634
On 30/01/15 14:20, Matwey V. Kornilov
Spinlocks imply memory barriers as far as I am aware...
Read here:
http://lxr.free-electrons.com/source/Documentation/memory-barriers.txt#L1634
On 30/01/15 14:20, Matwey V. Kornilov wrote:
2015-01-30 16:52 GMT+03:00 buyitian buyit...@gmail.com:
Please check the assembly code to double confirm
On Fri, Jan 30, 2015 at 11:02:01AM -0500, David Legault wrote:
The path used is generic in that it never changes, but the pointed block
device
underneath changes based on the hardware/configuration in place. So the idea
was to load a module passing the path as a module argument so I could
Hi,
On Fri, Jan 30, 2015 at 8:53 PM, Malte Vesper
malte.ves...@postgrad.manchester.ac.uk wrote:
Spinlocks imply memory barriers as far as I am aware...
Read here:
http://lxr.free-electrons.com/source/Documentation/memory-barriers.txt#L1634
And may be here aswell,
2015-01-30 16:52 GMT+03:00 buyitian buyit...@gmail.com:
Please check the assembly code to double confirm the GCC behavior.
Why will GCC change the order as what you mentioned? Only assembly code can
tell you.
It does not change at the moment. I think it can change it.
Because from line
在 2015年1月30日，20:43，Matwey V. Kornilov matwey.korni...@gmail.com 写道：
Hi,
I have the following code
int ret = 0;
unsigned long irqflags;
spin_lock_irqsave(lock, irqflags);
//...
ret = hdl-count;
//...
Ok for the sake of correctness and robustness of caeser cipher I have made
the suggested changes to it and the code is posted here:
https://github.com/bawejakunal/wrapfs-caeser/blob/master/mmap.c Now coming
back to the actual problem can someone please help me as to why isn't the
encrypted data
Ok somehow after introducing the robustness in caeser cipher it is working
correctly. Thanks. But the questions still remains why wasn't the data
being written to the file previously ?
*Kunal Baweja*
Undergraduate B.E. (Hons.) Computer Science
Birla Institute Of Technology Science, Pilani
K.K.
On Fri, 2015-01-30 at 09:08 +0100, Xavier Naveira wrote:
Why doesn't the Linus tree have tags for the minor version updates of
the kernel, ie, 3.18.1, 3.18.2 etc? If i do:
$ git tag | grep 3\.18
The result is:
v3.18
v3.18-rc1
v3.18-rc2
v3.18-rc3
v3.18-rc4
v3.18-rc5
v3.18-rc6
Hi,
I am currently working on implementing a simple encrypted file system using
a stackable file system WrapFS http://wrapfs.filesystems.org/. In order
to do so, as I read in the WrapFS mailing list
http://www.fsl.cs.sunysb.edu/pipermail/wrapfs/2011-November/58.html
one needs to implement
HI,
Kindly refer the following link that implements a minimal encryption over
wrapfs.
https://github.com/piekill/wrapfs
Go through the wrapfs_encrypt in wrapfs_readpage and wrapfs_decrypt in
wrapfs_writepage.
Regards,
Saket Sinha
On Fri, Jan 30, 2015 at 3:56 PM, Kunal Baweja
Hi all,
Why doesn't the Linus tree have tags for the minor version updates of
the kernel, ie, 3.18.1, 3.18.2 etc? If i do:
$ git tag | grep 3\.18
The result is:
v3.18
v3.18-rc1
v3.18-rc2
v3.18-rc3
v3.18-rc4
v3.18-rc5
v3.18-rc6
v3.18-rc7
X
___
I see, thank you Paul!
X
On Fri, Jan 30, 2015 at 9:14 AM, Paul Bolle pebo...@tiscali.nl wrote:
On Fri, 2015-01-30 at 09:08 +0100, Xavier Naveira wrote:
Why doesn't the Linus tree have tags for the minor version updates of
the kernel, ie, 3.18.1, 3.18.2 etc? If i do:
$ git tag | grep 3\.18
Yeah I was trying something similar only but with a much simpler Caeser
cipher function of my own written as below:
void encrypt(char *data, char *encrypted, size_t size)
{
unsigned int i;
for(i=0;i(unsigned int)size;i++)
encrypted[i] = data[i] + 3;
printk(KERN_INFO
... but will take a while to set up. i want to write a short tutorial
on kobjects, sysfs and attributes so i want to make absolutely sure i
understand them (which is something i should understand anyway. :-)
from sysfs.h and kobject.h, we have the definition of the generic
kernel-wide
Hi,
I have the following code
int ret = 0;
unsigned long irqflags;
spin_lock_irqsave(lock, irqflags);
//...
ret = hdl-count;
//...
spin_unlock_irqrestore(lock, irqflags);
return ret;
I would like to be sure, that ret
On Fri, 30 Jan 2015 17:18:21 +0530, Kunal Baweja said:
void encrypt(char *data, char *encrypted, size_t size)
{
unsigned int i;
for(i=0;i(unsigned int)size;i++)
encrypted[i] = data[i] + 3;
printk(KERN_INFO %s,encrypted);
return;
}
So in the given code wherever u
Obviously I am writing the encrypted data :-/ I will post my code on github
in an hour so that everyone gets to know what exactly I am doing :-)
On 6:44pm, Fri 30-Jan-2015 null valdis.kletni...@vt.edu wrote:
On Fri, 30 Jan 2015 17:18:21 +0530, Kunal Baweja said:
void encrypt(char *data, char
Hi devendra, it's not necessary to wrap around the characters in caeser
cipher by taking a modulus like you pointed out, there are many variants of
it. Anyways my actual problem is that the encrypted data is not being
written into the file whereas if I don't make a call to the encrypt
function
On Fri, 30 Jan 2015 06:55:53 -0500, devendra.aaru said:
This is not caesar's cipher. If your buffer contains alphabets then only
you can apply caesar cipher.
It should be something like
encrypted[i] = (data[i] - 3) % 26;
Consider the sequence of 4 hex bytes 0x17314B65. Your code
On Fri, 30 Jan 2015 13:17:10 +, Kunal Baweja said:
Obviously I am writing the encrypted data :-/
Just checking. You'd be *amazed* at how many times in the last 35 years
of code hacking, I've asked questions like that and there's a 10 second
pause before the person goes into Emily Litella
Hello all,
Have a little question about gdt initialization. We can see the following:
[GDT_ENTRY_BOOT_CS] = GDT_ENTRY(0xc09b, 0, 0xf),
in the arch/x86/boot/pm.c. Why accessed bit is set here (9b)? I see
that it was not set (9a) in the earliest versions. What's reason was
to change it?
--
On Fri, Jan 30, 2015 at 6:48 AM, Kunal Baweja bawejakuna...@gmail.com
wrote:
Yeah I was trying something similar only but with a much simpler Caeser
cipher function of my own written as below:
void encrypt(char *data, char *encrypted, size_t size)
{
unsigned int i;
hmmm ... i think i made a mess of that last
question/explanation so let me think about it more. darn.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
i'll try this one more time, but much more concisely. so far, i've
seen two different ways to create a kobject's attributes and register
callback routines for them:
the first general way i've seen is in mm/ksm.c, where each attribute
is enclosed in a surrounding kobj_attribute structure,
26 matches
Mail list logo
